Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


For a Windows 10 submission, the input package and the included files must be signed with sha256 sig

MDHMDH Member Posts: 44

I recently got a new EV cert from SSL.com. The cert was cheap ($269/yr) and going through validation was easy but the YubiKey token didn't work and it took days of back-and-forth with support to finally get it working. To make up for sending a defective token, they gave me a free 3 year OV cert. Besides having to put in the PIN every time I sign with the EV, it all seemed to work out. Until I just tried to submit for attestation signing.

The signature algorithm for my new cert is sha384ECDSA. Partner Center rejected my package saying:

"For a Windows 10 submission, the input package and the included files must be signed with sha256 signature algorithm."

Does Partner Center really not support sha384ECDSA certificates? SSL.com is listed on Microsoft's own website as a provider for EV certs.

Has anyone else had this issue?

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,107

    I’m thinking’ you got an EV SSL cert… not an EV Code Signing cert, which is what’s required.

    Just a guess.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MDHMDH Member Posts: 44

    Nope. Definitely got a EV code signing cert. Not my first rodeo so not that stupid (although maybe going with SSL.com wasn't the smartest).

    signtool.exe verify /pa /ph /v /d "..."
    
    Verifying: "..."
    
    Signature Index: 0 (Primary Signature)
    Hash of file (sha256): 13C0E3C6A65437BFE44A0FE2CF180294D3F9FEBB1FF7B1E4CC7ED93D0121FD2F
    
    Signing Certificate Chain:
        Issued to: SSL.com EV Root Certification Authority RSA R2
        Issued by: SSL.com EV Root Certification Authority RSA R2
        Expires:   Fri May 30 14:14:37 2042
        SHA1 hash: 743AF0529BD032A0F44A83CDD4BAA97B7C2EC49A
    
            Issued to: SSL.com EV Root Certification Authority ECC
            Issued by: SSL.com EV Root Certification Authority RSA R2
            Expires:   Fri Feb 12 14:08:58 2027
            SHA1 hash: 533815051A57FB0D8E0B231F9D3F7789A59CBEA9
    
                Issued to: SSL.com EV Code Signing Intermediate CA ECC R2
                Issued by: SSL.com EV Root Certification Authority ECC
                Expires:   Fri Mar 03 15:37:45 2034
                SHA1 hash: 7DC509CC760F073EE038040507C27858402D3B19
    
                    Issued to: ...
                    Issued by: SSL.com EV Code Signing Intermediate CA ECC R2
                    Expires:   ...
                    SHA1 hash: ...
    
    The signature is timestamped: Sat Jul 03 14:45:26 2021
    Timestamp Verified by:
        Issued to: DigiCert Assured ID Root CA
        Issued by: DigiCert Assured ID Root CA
        Expires:   Sun Nov 09 20:00:00 2031
        SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
    
            Issued to: DigiCert SHA2 Assured ID Timestamping CA
            Issued by: DigiCert Assured ID Root CA
            Expires:   Tue Jan 07 08:00:00 2031
            SHA1 hash: 3BA63A6E4841355772DEBEF9CDCF4D5AF353A297
    
                Issued to: DigiCert Timestamp 2021
                Issued by: DigiCert SHA2 Assured ID Timestamping CA
                Expires:   Sun Jan 05 20:00:00 2031
                SHA1 hash: E1D782A8E191BEEF6BCA1691B5AAB494A6249BF3
    
    SignTool Warning: No page hashes are present.
    
    Successfully verified: "..."
    
    Number of files successfully Verified: 1
    Number of warnings: 1
    Number of errors: 0
    
  • MDHMDH Member Posts: 44

    And I see I'm not the only one with this problem. @Lakelands posted about the same error a few weeks back.

    Maybe too soon to say that Microsoft Partner Center has a bug but the fact the files validate fine on Windows both with signtool and Explorer definitely says something is wrong somewhere.

  • LakelandsLakelands Member Posts: 13

    Microsoft examined one of our submissions that failed with the subject error. Microsoft explained the reason ev certs from ssl.com do not work is submission packages must be signed with SHA2 only. When a ssl ev cert is used there is both a SHA2 and a SHA384 signature. So far ssl.com have offered no solution to this problem.

  • MDHMDH Member Posts: 44

    @Lakelands said:
    Microsoft examined one of our submissions that failed with the subject error. Microsoft explained the reason ev certs from ssl.com do not work is submission packages must be signed with SHA2 only. When a ssl ev cert is used there is both a SHA2 and a SHA384 signature. So far ssl.com have offered no solution to this problem.

    Thanks @Lakelands Makes you wonder why Microsoft lists SSL.com as a valid EV cert provider. This is definitely a Microsoft created problem but like most issues they will just ignore it. Just like cross-signing so now I have to set up a test rig for HLK/HCK for tests that won't pass for my isolation filters. I also don't understand how SSL.com can sell an EV cert that doesn't validate for the ONE THING it has to validate for. The entire code signing is so broken. Google is now requiring you provide private keys before you can publish new Android apps. Probably just a matter of time before Microsoft does something just as stupid.

    Does anyone from Microsoft read these boards? Do they not realize how terrible their policies are?

  • craig_howardcraig_howard Member Posts: 239

    Hmm ... or, SSL.com can stop issuing a SHA384 with their EV cert. You, as the paying customer, have the ability to make that happen by singing loud and strong how the SSL.com cert is useless and taking your business elsewhere. I guarantee that folks read forums like this to see what providers get it "right" and which "get it wrong" and if SSL.com sees their business drop as a result will likely stop issuing bad cert's ...

  • MDHMDH Member Posts: 44

    @craig_howard said:
    Hmm ... or, SSL.com can stop issuing a SHA384 with their EV cert. You, as the paying customer, have the ability to make that happen by singing loud and strong how the SSL.com cert is useless and taking your business elsewhere. I guarantee that folks read forums like this to see what providers get it "right" and which "get it wrong" and if SSL.com sees their business drop as a result will likely stop issuing bad cert's ...

    These are standards. If Windows can validate a sha384ECDSA, then Partner Center should too. Microsoft should also then not list SSL.com as a EV provider on their page of suggested providers. This is completely Microsoft issue.

  • craig_howardcraig_howard Member Posts: 239

    Hmm ... and so here you sit, with a certificate that you can't use, telling MS that it's their problem ... in the meantime others are able to make forward progress getting stuff signed. Were I in your situation I would a) ask on the list what providers people have gotten signatures with recently and b) get one of those cert's from a provider that others are using then c) drop the SSL.com cert into the round file and get back to making forward progress ...

  • MDHMDH Member Posts: 44
    edited July 2021

    Does Microsoft not do due diligence on their recommended providers? Are we peasantry just supposed to play Russian roulette by wasting time and money getting verified to satisfy Microsoft's rules to only find out afterwards that the product is busted? Gimme a break. I repeat, if Partner Center can't recognize sha384ECDSA then yes it is Microsoft's problem. You think sha256 will last forever?

    If you have something actually useful to add, instead of pontifications on what I should do, I'd love to hear it. Otherwise, you opinion is noted.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,107

    What Mr. @craig_howard said.

    You wanted a cheap cert, you went with SSL.COM. Use Digicert like everyone else, and avoid the problem entirely.

    Microsoft says SSL.COM meets their criteria. Who knows why/when SSL.COM started issuing certs with sha384ECDSA…. And I agree it should all work. And I get that it’s frustrating. But I’ve gotta say, if this is your biggest problem in driver development, you’re a lucky person.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 38

    Since it's not your first rodeo, maybe you've already ruled this out too. But since you mentioned "for my troubles, they also gave me a free three-year OV cert" in addition to the EV cert you purchased, is the outcome any different if you sign with the OV cert?

    Meaning, you indeed must have an EV cert, and you have already uploaded the EV cert to your Microsoft Partner Portal account. If you also upload the OV cert to your Microsoft Partner Portal account, and then sign the submission using the OV cert instead of the EV cert, does the OV cert also have the same sha384 issue as confirmed to exist when using the SSL.com EV certificate signature?

  • MDHMDH Member Posts: 44

    @Alan_Adams said:
    Since it's not your first rodeo, maybe you've already ruled this out too. But since you mentioned "for my troubles, they also gave me a free three-year OV cert" in addition to the EV cert you purchased, is the outcome any different if you sign with the OV cert?

    Meaning, you indeed must have an EV cert, and you have already uploaded the EV cert to your Microsoft Partner Portal account. If you also upload the OV cert to your Microsoft Partner Portal account, and then sign the submission using the OV cert instead of the EV cert, does the OV cert also have the same sha384 issue as confirmed to exist when using the SSL.com EV certificate signature?

    Thanks for the suggestion. The OV is sha256 but unfortunately it did not work in any combination I tried.

    Driver: EV, CAB: OV "SignatureValidationFailed"
    Driver: OV, CAB: OV "SignatureValidationFailed"
    Driver: OV, CAB: EV Original error that I already posted
    Driver: EV, CAB: EV Original error that I already posted

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 38
    edited July 2021

    The driver binaries need not be signed at all, and are not part of any validation or checking that is occurring. If a signature is already present on the binaries, the Microsoft signature will be added in addition. And since cross-signing is or soon to be deprecated, "a signature already on the binaries prior to submission" would seem to be of little or no use. And literally "gets in the way" trying to use the signed binaries on down-level platforms.

    Signature of the .CAB being submitted is what's being evaluated. Since you didn't mention specifically the same error message again, "For a Windows 10 submission, the input package and the included files must be signed with sha256 signature algorithm", it makes me wonder whether the OV signature has not been uploaded to your Microsoft Partner Portal account? And that's the reason for the "SignatureValidationFailed"?

    Meaning same as when you uploaded your EV signature to the Microsoft Partner Portal account by downloading and signing their "SignableFile.bin" artifact, go through those same steps again but using the OV certificate. Such that when you're done, the thumbprints of your OV certificate and your EV certificate are both listed in the Certificate Management section of your Microsoft Partner Portal account.

    Maybe that's what you already did for the current test; just confirming to be sure.

    The EV certificate is what's required in order to have a Microsoft Partner Portal account at all. But submissions can be signed using any certificate listed in your Microsoft Partner Portal account; not just the EV certificate. The only exception to this I'm currently aware of is LSA Plug-In signing, which requires submissions be signed with the EV certificate. Attestation, HLK/HCK, and UEFI submissions do not require being signed with the EV certificate.

  • MDHMDH Member Posts: 44

    Amazing! Uploading the OV and using that to sign the CAB works. I didn't even think to upload the OV because even the 'SignableFile.bin" page says it needs to be an EV.

    Still feels like a busted Partner Center issue to me. Shouldn't have to buy a second cert on top of the EV to make this process work. But thanks for your help.

  • DenisDenis Member Posts: 3

    Hello, i have same problem. i've renew certificate on sectigo.com and now it has sha384 algorithm, microsoft also doesn't accept my submission, i have write to microsoft support, live chat and twitter and didn't received any answers.

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 38

    As Peter has alluded to in other posts, the control you have over your own fate here is to try and obtain a certificate which has an sha256 signature algorithm. It can be -- but does not have to be -- your EV certificate. As it was in MDH's case in this thread, where a separate OV certificate was obtained and used for signing Microsoft Partner Portal submissions instead.

    So you could talk to sectigo.com, to tell them that the Microsoft Partner Portal does not accept submissions using your new EV certificate. And see whether sectigo.com has any free or non-free solutions for you. Such as re-issuing your EV certificate (doubtful), giving you a separate OV certificate to use (maybe), or saying you'll simply need to buy a separate OV certificate with only an sha256 signature algorithm.

    Yes, you should also be trying to contact Microsoft regarding the issue. And presumably, Microsoft will eventually fix this issue, whether they respond to any of your inquires or not. But presuming you have products that need to be signed now, that may not be something you can wait for.

  • DenisDenis Member Posts: 3
    edited July 2021

    I asked to sectigo give me OV certificate, but they said that it also has sha384 algorithm, so currently we can't sign our driver correct :(

  • MikeSMikeS Member Posts: 32

    Hi folks,
    Could someone please explain how to check which SHA algorithm a particular EV code certificate implements, SHA1/SHA256/SHA384?
    Couldn't find any way to check this out by either signtool or Safenet tools.
    Thank you!

  • MikeSMikeS Member Posts: 32

    @MikeS said:
    Hi folks,
    Could someone please explain how to check which SHA algorithm a particular EV code certificate implements, SHA1/SHA256/SHA384?
    Couldn't find any way to check this out by either signtool or Safenet tools.
    Thank you!

    Found one way to do this, through right clicking on the signed file in Windows, selecting Properties -> Digital Signatures -> Selecting the signature -> Details -> View Certificate -> Details -> Signature Algorithm.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 16-20 October 2023 Live, Online
Developing Minifilters 13-17 November 2023 Live, Online
Internals & Software Drivers 4-8 Dec 2023 Live, Online
Writing WDF Drivers 10-14 July 2023 Live, Online