Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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
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?
Howdy, Stranger!
| 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! | ||
| Internals & Software Drivers | 19-23 June 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
Comments
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
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: 0And 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.
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?
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.
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 ...
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.
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
DigiCert is going that way too...
https://knowledge.digicert.com/alerts/code-signing-new-minimum-rsa-keysize.html
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
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.
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.
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.
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.
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
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.