Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Windows still loads drivers with expired cross certificates

antsteelantsteel Member Posts: 9
edited April 16 in NTDEV
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?

Comments

  • shaun_hollingworthshaun_hollingworth Member Posts: 7
    edited April 17

    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.

  • shaun_hollingworthshaun_hollingworth Member Posts: 7

    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.

  • Gabe_JonesGabe_Jones Member Posts: 89

    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.

  • antsteelantsteel Member Posts: 9
    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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,958

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • antsteelantsteel Member Posts: 9
    > @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.
  • Gabe_JonesGabe_Jones Member Posts: 89
    edited April 19

    @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.

  • shaun_hollingworthshaun_hollingworth Member Posts: 7

    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.

  • henrik_meidahenrik_meida Member Posts: 44
    edited April 20

    @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..

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,436

    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

  • antsteelantsteel Member Posts: 9
    > @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).
  • shaun_hollingworthshaun_hollingworth Member Posts: 7
    edited April 20

    @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.

  • antsteelantsteel Member Posts: 9
    > @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?
  • shaun_hollingworthshaun_hollingworth Member Posts: 7
    edited April 20

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,958

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online