OK, let's see if I can help clear SOME things up -- Though I'm not going to be able to clear up nearly as much as I had hoped earlier.
I got our eToken today, and it seems OSR's new code signing cert is issued by Digicert, not Entrust. My bad. But, I'm not sure that'd help anything no matter what.
I'm going to post this here, then I'm going to clean it up and make it into a blog post and try to get the word out across the industry. Comments/thoughts appreciated.
Before I even start, let me acknowledge that this is an unholy mess.
This is what I know as of this afternoon.
- This discussion is about driver signing on down-level versions of Windows, such as Windows 7, Windows 8, and Windows 8.1 -- This discussion has nothing at all to do with driver signing for Windows 10.
- To enable a driver to be installed on down-level versions of Windows, the driver package needs to be signed either by a Microsoft certificate or using a third-party kernel-mode code signing certificate that has been cross-signed by the CA. Both certificates need to be valid when the driver is signed.
- This discussion results from MSFT's policy to discontinue support for cross-signing drivers to enable them to be installed on down-level version of Windows. This isn't an arbitrary decision, but rather is driven by technical issues around the way the existing certs work.
- According to the MSFT Trusted Root Program (TRP) policy, after 1 July 2021CAs cannot issue kernel-mode code signing certificates. Certificates in violation of Microsoft TRP policies are subject to revocation.
- Despite repeated pleas to provide an alternate way to sign drivers, as of today (2 March 2021) the only way MSFT says that you'll be able to install drivers on down-level versions of Windows is to make your drivers pass the WHQL tests.
- Here's where the Community gets screwed: It is technically impossible for many drivers to pass the WHQL tests (consider, for example, drivers that load/run on certain embedded systems that can't work as clients for the HCKs).
Cross-Signing Certs Valid After 1 July 2021?
- Folks in the community have noticed that new cross-signing certificates have been issued, with expiration dates that run BEYOND 1 July 2021.
- There are exactly 5 such certificates that I can find as of today (2 March 2021). They are from "Entrust Root Certification Authority – G2", "AddTrust External CA Root", "GoDaddy Class 2 Certification Authority", "Starfield Class 2 Certification Authority", and "UTN-USERFirst-Object"
- It seems logical that if you had a kernel-mode code signing cert that chains up to one of these specific CAs, you could continue to use it along with one of the cross-certs above to sign kernel-mode drivers until either your code signing cert expires or the cross-cert expires, whichever comes first.
- The catch: I can't find a way to purchase a relevant code-signing cert from any of these CAs (AddTrust and UTN-USERFirst-Object are both part of Sectigo now). If you can, let us know!
- Remember: The goal here is to be able to install drivers on down-level versions of Windows, without having to pass WHQL.
- One solution that we know works on Windows 7: Attestation Sign your driver package and binary for Windows 10. The resulting driver package will install on Windows 7 (with KB4474419, which enabled SHA-256 signing installed). Note that this works as long as you DO NOT sign the driver binary with your own signature before you submit it to MSFT for Attestation Signing.
- Attestation Signing your driver package for Windows 10 will also allow non-PnP drivers drivers to be installed on Windows 8.1(including right-click install using an INF) -- This does not, however, work for PnP drivers.
That's what I know as of this afternoon, and I sincerely hope it's helpful.
I am in (almost) daily communication with MSFT on this issue. I've been told that we should see something more from them, in terms of a policy clarification or something soon. Yes... we've heard that before.