Windows still loads drivers with expired cross certificates

Hello, As you know most of the cross signed certificates expired yesterday. I have an EV cert from Digicert that I use to sign my driver. The cross signed certicate expired yesterday, and yet, I’m still able to use it to sign and load my driver just fine on Windows 10, without submitting it for attestation signing. Neither signtool or Windows complain about the cross certificate being expired. It doesn’t seem like there is any validation, unlike the page on Microsoft website suggests. That seems kind of weird to me. Is anyone else seeing the same behaviour?

2 Likes

Yes, I have found exactly the same behaviour here with a build this morning. I too have EV Digicert code signing certificate. The driver built today worked fine, with Secure Boot disabled of course. For UEFI systems with Secure boot enabled, the MS signature is required for current Windows 10 versions of course.

In the past, when the cross signing certs have expired, I have always had a new one available from the vendor before the expiry date, and added them to my dev box so I’ve never tried to see exactly what happens if you still used the expired certificate.

I have to say that I think Microsoft have completely lost the plot. They moan about people writing bad drivers, and not doing things correctly - but I have found that the guidance they actually provide seems to be dreadful. Some things are even contradictory between different documents.

As other people have pointed out, as far as drivers are concerned, we also NEED to have a vendor’s signature on the driver, so people know for sure the driver is part of the software package they have installed.

I am 64 years old, and approaching retirement. I think I will simply retire a bit early rather than deal with this increasing control freakery. I can perfectly understand if people start to move to Linux systems for specialist projects. It seems the only logical thing to do.

Yes, I have found exactly the same behaviour here with a build this morning. I too have EV Digicert code signing certificate. The driver built today worked fine, with Secure Boot disabled of course. For UEFI systems with Secure boot enabled, the MS signature is required for current Windows 10 versions of course.

In the past, when the cross signing certs have expired, I have always had a new one available from the vendor before the expiry date, and added them to my dev box so I’ve never tried to see exactly what happens if you still used the expired certificate.

So the expiration on the cross-cert is completely meaningless from a KMCS standpoint? That explains why Microsoft was requiring CAs to revoke signing certs that are used to sign kernel-mode driver packages.

Is this revokation only for non-EV certificates? As far as I know Windows never check if the certificate has been revoked, and just loads the driver anyway, so I’m not sure how this would make a difference. It probably can’t check for revokation either way since you wouldn’t have internet access while the system is booting.

So the expiration on the cross-cert is completely meaningless from a KMCS standpoint?

Yes. We’ve always known that. KMCS doesn’t scan through the whole cert chain. It doesn’t have the time, and it doesn’t have network resources. It certainly doesn’t do revocation checking. All it does is make sure that your chain ends in the “Microsoft Code Verification Root”. The only way to get the “Microsoft Code Verification Root” is through signtool with a cross cert; that’s where the expirations and revocations matter.

> @Tim_Roberts said: > The only way to get the “Microsoft Code Verification Root” is through signtool with a cross cert; that’s where the expirations and revocations matter. But as shown in our testing above it’s not currently enforced. What’s the point of the new policy then if it doesn’t change anything? Unless they plan to actually enforce it when they release 21H1 or 21H2.

@Tim_Roberts said:

Yes. We’ve always known that. KMCS doesn’t scan through the whole cert chain. It doesn’t have the time, and it doesn’t have network resources. It certainly doesn’t do revocation checking. All it does is make sure that your chain ends in the “Microsoft Code Verification Root”. The only way to get the “Microsoft Code Verification Root” is through signtool with a cross cert; that’s where the expirations and revocations matter.

I’m surprised that signtool didn’t even bother to check the date, then.

A verification of a boot start configured driver with cross signature expired.
This still loads - even with test signing disabled. Apologies if this is necessarily long to include all relevant information.

NO ms root signature mentioned in this chain.
Note that this is a boot driver needed to be loaded on OS startup.

Lower down this post I show the verification from a released driver signed before the cross certificate expired.


The test driver which still runs with TESTSIGNING disabled, signed after the cross certificate expired:

C:\Windows\System32\drivers>signtool verify /v /kp dcpp2k.sys
Verifying: Dcpp2k.sys
SHA1 hash of file: 94582AE01A0A03D1D11554DB0B25DF0782760673
Signing Certificate Chain:
Issued to: DigiCert High Assurance EV Root CA
Issued by: DigiCert High Assurance EV Root CA
Expires: 10/11/2031 01:00:00
SHA1 hash: 5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25


Issued to: DigiCert EV Code Signing CA (SHA2)
Issued by: DigiCert High Assurance EV Root CA
Expires: 18/04/2027 13:00:00
SHA1 hash: 60EE3FC53D4BDFD1697AE5BEAE1CAB1C0F3AD4E3
Issued to: SecurStar GmbH
Issued by: DigiCert EV Code Signing CA (SHA2)
Expires: 26/07/2023 13:00:00
SHA1 hash: 0B0C1C4246FFCB808A253798981DEE04338F6D26


The signature is timestamped: 17/04/2021 11:09:06
Timestamp Verified by:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: 10/11/2031 01:00:00
SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43


Issued to: DigiCert SHA2 Assured ID Timestamping CA
Issued by: DigiCert Assured ID Root CA
Expires: 07/01/2031 13:00:00
SHA1 hash: 3BA63A6E4841355772DEBEF9CDCF4D5AF353A297


Issued to: DigiCert Timestamp 2021
Issued by: DigiCert SHA2 Assured ID Timestamping CA
Expires: 06/01/2031 01:00:00
SHA1 hash: E1D782A8E191BEEF6BCA1691B5AAB494A6249BF3


Successfully verified: Dcpp2k.sys


Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0


Now a previously released driver: (This driver also has an MS attestation signature on it added later.)


C:\Windows\System32\drivers>signtool verify /v /kp dcpp2k-mssigned.sys
Verifying: dcpp2k-MSSigned.sys
SHA1 hash of file: 8EDEDEC48DA68BA0CC6F1D9076C0AA82F11CC3F8
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: 01/11/2025 14:54:03
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3


Issued to: DigiCert High Assurance EV Root CA
Issued by: Microsoft Code Verification Root
Expires: 15/04/2021 20:55:33
SHA1 hash: 2F2513AF3992DB0A3F79709FF8143B3F7BD2D143


Issued to: DigiCert EV Code Signing CA (SHA2)
Issued by: DigiCert High Assurance EV Root CA
Expires: 18/04/2027 13:00:00
SHA1 hash: 60EE3FC53D4BDFD1697AE5BEAE1CAB1C0F3AD4E3


Issued to: SecurStar GmbH
Issued by: DigiCert EV Code Signing CA (SHA2)
Expires: 26/07/2023 13:00:00
SHA1 hash: 0B0C1C4246FFCB808A253798981DEE04338F6D26


The signature is timestamped: 25/09/2020 13:36:16
Timestamp Verified by:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: 10/11/2031 01:00:00
SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43


Issued to: DigiCert SHA2 Assured ID Timestamping CA
Issued by: DigiCert Assured ID Root CA
Expires: 07/01/2031 13:00:00
SHA1 hash: 3BA63A6E4841355772DEBEF9CDCF4D5AF353A297


Issued to: TIMESTAMP-SHA256-2019-10-15
Issued by: DigiCert SHA2 Assured ID Timestamping CA
Expires: 17/10/2030 01:00:00
SHA1 hash: 0325BD505EDA96302DC22F4FA01E4C28BE2834C5


Successfully verified: dcpp2k-MSSigned.sys


Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0


This released driver also contains a Microsoft “attestation” signature. I didn’t change anything in the signing command to sign the drivers in either case other than the Digicert cross signing certificate had expired. I really don’t get this. Where did the new Digicert certificates come from? Perhaps at 64 years old I’m too old for these major changes! Of course I don’t intend to release the newly signed driver. That would be too risky in my opinion.

@antsteel said:

@Tim_Roberts said:
The only way to get the “Microsoft Code Verification Root” is through signtool with a cross cert; that’s where the expirations and revocations matter.

But as shown in our testing above it’s not currently enforced. What’s the point of the new policy then if it doesn’t change anything?
Unless they plan to actually enforce it when they release 21H1 or 21H2.

But the beta version of 21H1 is released already for companies to test it before using it, and its the same as 20H2 as far as i can tell.

I doubt they would suddenly change the 21H1 in the last minute before people testing it, specially for something this big, right? i mean imagine they changing something in kernel checks in the last minute and all of the sudden many systems might not even boot because of a invalid signature on a boot driver… but then again its Microsoft so who knows whats inside their empty heads…

You probably want to take note of this clear statement from Microsoft about what will happen if you you push your cross signed drivers out into the world:

“Will I be able to continue signing drivers with a certificate that chains to a cross-cert that expires after July 1, 2021?
No, kernel-mode drivers must be signed with a WHQL signature after July 1st, 2021. You cannot use a certificate that chains to a cross-cert that expires after July 1, 2021 to sign kernel-mode drivers. Using these certificates to sign kernel-mode drivers after this date is a violation of the Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked by the CA. Additional certificates may be present on the kernel-mode driver, however Windows ignores those signatures for the purpose of validating the driver.”
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#will-i-be-able-to-continue-signing-drivers-with-a-certificate-that-chains-to-a-cross-cert-that-expires-after-july-1-2021

> @Mark_Roddy said: > You probably want to take note of this clear statement from Microsoft about what will happen if you you push your cross signed drivers out into the world: > > “Will I be able to continue signing drivers with a certificate that chains to a cross-cert that expires after July 1, 2021? > No, kernel-mode drivers must be signed with a WHQL signature after July 1st, 2021. You cannot use a certificate that chains to a cross-cert that expires after July 1, 2021 to sign kernel-mode drivers. Using these certificates to sign kernel-mode drivers after this date is a violation of the Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked by the CA. Additional certificates may be present on the kernel-mode driver, however Windows ignores those signatures for the purpose of validating the driver.” > https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#will-i-be-able-to-continue-signing-drivers-with-a-certificate-that-chains-to-a-cross-cert-that-expires-after-july-1-2021 This statement is about cross signed certificates that expire after July 1st, 2021 though. There are few of these, that are not listed in the article. It doesn’t say more about cross signed certificates that already expired (and are still working).

@antsteel said:

@Mark_Roddy said:

This statement is about cross signed certificates that expire after July 1st, 2021 though. There are few of these, that are not listed in the article. It doesn’t say more about cross signed certificates that already expired (and are still working).

But are they still working or is it something else? Note that the signing verification I posted of our working driver (signed after expiry of the cross signing certificate) has no Microsoft root certificates chained at all, according to the signtool verify list. There are only Digicert certificates listed. It seems the thing will somehow work without a Microsoft root certificate, and without the cross signed certificate. This looks like some serious thing to me.

> @shaun_hollingworth said: > But are they still working or is it something else? Note that the signing verification I posted of our working driver (signed after expiry of the cross signing certificate) has no Microsoft root certificates chained at all, according to the signtool verify list. There are only Digicert certificates listed. It seems the thing will somehow work without a Microsoft root certificate, and without the cross signed certificate. This looks like some serious thing to me. The driver shouldn’t load at all if it is not cross signed or attestation signed. Are you testing this on Windows 10?

@antsteel said:
The driver shouldn’t load at all if it is not cross signed or attestation signed. Are you testing this on Windows 10?

Yes I am testing on Windows 10 20H2. It is on a Dell Optiplex 9020 i7 dev box with secure boot currently disabled. Disabling Secure Boot allows cross signed drivers without MS HWQL or attestation certificates to load, which is how we have been testing our pre-production drivers on Windows 10 UEFI machines for years now. It’s easier just to ask our beta testers to disable secure boot whilst testing. If Secure Boot is enabled, then the MS signature is required.

The cross signed certificate allowed execution on older systems such as Windows 8, and Windows 7 (with the Sha256 updates applied) so previously to allow Windows 7 we've signed with cross signed certificates, and then submitted those to Microsoft portal for signing for Windows 10 with Secure Boot. This always seemed to work, but it perhaps might have worked anyway just with the MS signature apparently according to the latest info from OSR.

To be honest - I fail to understand why Microsoft are getting so strict about this, as it only affects older operating systems, or windows 10 running on older hardware on MBR/BIOS systems, or people using MBR based Windows 10 on new boxes booted with the CSM.

PS: (Edit)
Did you do a “signtool verify /v /kp” on your driver which you said still works? What was the result?

I fail to understand why Microsoft are getting so strict about this, as it only affects older operating systems,

This is a very old and very common disease within Microsoft. In Redmond, the current version of Windows is already uninteresting. They’re all using the next version, and thinking about the two versions after that. In their minds, no one uses Windows 1809 anymore, much less Windows 7. We in the trenches know that the real world is not like that, but that’s not the vision of the decision makers.