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/


Insider Preview build 22557 and later "A certificate was explicitly revoked by its issuer."

Alan_AdamsAlan_Adams Member - All Emails Posts: 25

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.

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,963

    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.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_AdamsAlan_Adams Member - All Emails Posts: 25

    @Peter_Viscarola_(OSR) said:
    ...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.

  • Nathan_KiddNathan_Kidd Member - All Emails Posts: 22
    via Email
    On 2022-05-02 8:11 a.m., Alan_Adams wrote:
    > 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
    helpful.

    -Nathan
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,526

    I wonder if this has anything to do with this pending change: https://cabforum.org/2021/06/30/ballot-sc47v2-sunset-subjectorganizationalunitname/

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!
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online
Writing WDF Drivers 12 September 2022 Live, Online