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.