Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
A new behavior we haven't been able to figure out yet is that starting in Windows 11 22H2 build 22557 and later, Windows refuses to start our Attestation-signed driver, citing CERT_E_REVOKED (0x800B010C), "A certificate was explicitly revoked by its issuer."
That's not actually the condition occurring, of course, because Microsoft's certificate has not actually been revoked. The same binary loads fine on shipping Windows 11 and Windows 10. It loads on all Windows 11 22H2 builds prior to 22557, too.
This failure can be demonstrated on all subsequent builds after 22557, up to and including the current 22598 build. Unfortunately Feedback Hub hasn't generated any response in months on this, and Professional Support of course won't touch an Insider Preview build behavior.
If you enable Test Signing mode, the same Attestation-signed driver is now allowed to load successfully. Enabling Test Signing of course requires disabling Secure Boot, too. But disabling Secure Boot alone does not allow Windows build 22557 or later to successfully load the driver. Nor does using F8 to select Disable Driver Signature Enforcement.
This is a software-only driver starting as SERVICE_SYSTEM_START, installed by a NetClient-class .INF, and assigned to the "TDI" driver start group. It is not the actual network redirector (not what registers with MUP, etc.) and is just a driver of supporting library functions. The driver does have an IOCTL interface. The Microsoft Attestation-signed signature is the only signature on the binary, and the Microsoft Attestation-signed signature is the only signature on the .CAT file used during installation.
Finally, I note that Windows 11 22H2 build 22557 and later does not fail to load our file system filter drivers, which were signed during the same Attestation signing session and installed by the same NetClient-class .INF. Again, just another pencil mark in the column of "A certificate was explicitly removed by it's issuer" not being the actual condition which is occurring.
If anyone is experiencing or has solved a similar observation, or knows of a Microsoft announced change that maybe I'm failing to connect to this new observed behavior, we will appreciate any input that could help progress this investigation.
|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|
That is, seriously, scary. However, before we (all) panic... I WILL note that stuff like this has simply been broken in pre-release builds before. So... it MIGHT not be a sign of some pending policy change.
Indeed. And since the evidence does not yet point to the failure actually having anything to do with "the certificate" (despite the error code used), I'm not yet thinking that "Attestation signing" is really what's being targeted here. But we have no idea what _is _being targeted here yet, either.
For example, our legacy file system filter driver (which Windows 11 22H2 does continue to load successfully, and was signed during the same Attestation signing session, and installed as part of the same .INF and .CAT) is located in \Windows\System32\drivers. Whereas the driver(s) being failed have always historically loaded from Program Files. But when I hacked putting the driver(s) over into \System32\drivers\, Windows 11 22H2 was still not happy and still cited CERT_E_REVOKED when failing to load them.
But those are the kinds of "Why doesn't Windows like this driver any more?" conditions I'm now looking for as being "some reason other than the certificate", even though Windows 11 22H2 is reporting the driver load failure as CERT_E_REVOKED.
And we too had our fingers crossed that "maybe this is just temporary." But the first build in which this started, build 22557, was published back in February 2022. Which is starting to feel like a long time for the issue to still exist, and to be unable to get any response out of Microsoft regarding why its happening, if intentional.
> But those are the kinds of "Why doesn't Windows like this driver any
> more?" conditions I'm now looking for as being "some reason other
> than the certificate", even though Windows 11 22H2 is reporting the
> driver load failure as CERT_E_REVOKED.
When all else fails, I've found windbg tracing useful to help get a clue
of what the black box doesn't like.
E.g. from the driver install function run 'wt -oR -l ' on the
working driver and non-working driver. Compare where the return values
start to differ. If you're lucky one of the error values will be more
I wonder if this has anything to do with this pending change: https://cabforum.org/2021/06/30/ballot-sc47v2-sunset-subjectorganizationalunitname/
For what it's worth, we are continuing to see this issue even on build 22610, and I'm in the process of checking build 22622. We have still not been able to pinpoint what Windows is declaring at driver load / driver start time (not installation time) as CERT_E_REVOKED.
Out of curiosity, can anyone attest to successfully loading / running an Attestation-signed software-only driver on Windows Insider Preview build 22557 or later? That Windows Insider Preview is rejecting specifically Attestation-signed drivers is of course one of the possibilities & concerns, and something folks signing hardware drivers via HLK testing might not be encountering.