Hi,
I have a signed driver (not timestamped), that is still not expired and is valid. the digital signature tab also says that its OK.
but the problem is, when i try to load it, windows says that it cannot verify the digital signature! is this normal? Considering that expiration date is still in few months, there should be no need to timestamp it correct? I checked the certificate path, and all 3 are valid and OK.
What are the possible causes for this problem? I have tried it in windows 7/10, without any secure boot, but no luck.
Is it cross-signed with the proper cross-certificate?
@Tim_Roberts said:
Is it cross-signed with the proper cross-certificate?
Correct. so this can’t be because of timestamp right? considering that the certificate is not expired yet.
Where exactly does it say that - kernel mode (after the installation, in the driver’s properties), or user mode (dialogs during installation)?
What does signtool verify /kp /v driver.sys say? And the same for the CAT, if you are using it.
Do you just get the scary warning? Does the driver otherwise install?
What does setupapi.dev.log say?
Peter
@CaptainFlint said:
Where exactly does it say that - kernel mode (after the installation, in the driver’s properties), or user mode (dialogs during installation)?
What does signtool verify /kp /v driver.sys say? And the same for the CAT, if you are using it.
This is the error:
File is not timestamped.
SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1
So what does that mean that it doesn’t chain to a Microsoft Root cert? the top one in chain is this :
Signing Certificate Chain:
Issued to: COMODO RSA Certification Authority
Issued by: COMODO RSA Certification Authority
Expires: Mon Jan 18 16:59:59 2038
@“Peter_Viscarola_(OSR)” said:
Do you just get the scary warning? Does the driver otherwise install?
What does setupapi.dev.log say?
Peter
@“Peter_Viscarola_(OSR)” said:
Do you just get the scary warning? Does the driver otherwise install?
What does setupapi.dev.log say?
Peter
Its not a scary warning, it straight up blocks it from loading and says it cannot verify the digital signature. what is setupapi.dev.log? I’m not familiar with it. I’m loading it with osrloader, i don’t see any log getting generated anywhere.
@john_smith1978 said:
So what does that mean that it doesn’t chain to a Microsoft Root cert? the top one in chain is this :
You need to look at the cross-certificate chain. For a properly signed driver the output should look something like this:
! ! Verifying: viosock.sys ! ! Signature Index: 0 (Primary Signature) ! Hash of file (sha256): 721F27B5D9B375AE0B39233A7FAFEFF0439CFE2F8BF32D324D63CC6E47AB99F7 ! ! Signing Certificate Chain: ! Issued to: DigiCert High Assurance EV Root CA ! Issued by: DigiCert High Assurance EV Root CA ! Expires: Mon Nov 10 03:00:00 2031 ! SHA1 hash: 5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25 ! ! Issued to: DigiCert EV Code Signing CA (SHA2) ! Issued by: DigiCert High Assurance EV Root CA ! Expires: Sun Apr 18 15:00:00 2027 ! SHA1 hash: 60EE3FC53D4BDFD1697AE5BEAE1CAB1C0F3AD4E3 ! ! Issued to: Virtuozzo International GmbH ! Issued by: DigiCert EV Code Signing CA (SHA2) ! Expires: Fri Mar 19 15:00:00 2021 ! SHA1 hash: 54CC6CF908F961396FB8F151D723A99BFC392F5A ! ! The signature is timestamped: Tue Oct 27 19:20:20 2020 ! Timestamp Verified by: ! Issued to: DigiCert Assured ID Root CA ! Issued by: DigiCert Assured ID Root CA ! Expires: Mon Nov 10 03:00:00 2031 ! SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 ! ! Issued to: DigiCert SHA2 Assured ID Timestamping CA ! Issued by: DigiCert Assured ID Root CA ! Expires: Tue Jan 07 15:00:00 2031 ! SHA1 hash: 3BA63A6E4841355772DEBEF9CDCF4D5AF353A297 ! ! Issued to: TIMESTAMP-SHA256-2019-10-15 ! Issued by: DigiCert SHA2 Assured ID Timestamping CA ! Expires: Thu Oct 17 03:00:00 2030 ! SHA1 hash: 0325BD505EDA96302DC22F4FA01E4C28BE2834C5 ! ! Cross Certificate Chain: ! Issued to: Microsoft Code Verification Root ! Issued by: Microsoft Code Verification Root ! Expires: Sat Nov 01 16:54:03 2025 ! SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3 ! ! Issued to: DigiCert High Assurance EV Root CA ! Issued by: Microsoft Code Verification Root ! Expires: Thu Apr 15 22:55:33 2021 ! SHA1 hash: 2F2513AF3992DB0A3F79709FF8143B3F7BD2D143 ! ! Issued to: DigiCert EV Code Signing CA (SHA2) ! Issued by: DigiCert High Assurance EV Root CA ! Expires: Sun Apr 18 15:00:00 2027 ! SHA1 hash: 60EE3FC53D4BDFD1697AE5BEAE1CAB1C0F3AD4E3 ! ! Issued to: Virtuozzo International GmbH ! Issued by: DigiCert EV Code Signing CA (SHA2) ! Expires: Fri Mar 19 15:00:00 2021 ! SHA1 hash: 54CC6CF908F961396FB8F151D723A99BFC392F5A ! ! ! Successfully verified: viosock.sys ! ! Number of signatures successfully Verified: 1 ! Number of warnings: 0 ! Number of errors: 0 !
The “Signing Certificate Chain” block shows you the main certificate you used for signing, and its chain up to the CA root. The “Cross Certificate Chain” prolongs that up to the Microsoft root, which makes it valid for the kernel.
There should be two “top-level” certificates, and one of them need to end at the “Microsoft Code Verification Root”.
@CaptainFlint said:
The “Signing Certificate Chain” block shows you the main certificate you used for signing, and its chain up to the CA root. The “Cross Certificate Chain” prolongs that up to the Microsoft root, which makes it valid for the kernel.
@Tim_Roberts said:
There should be two “top-level” certificates, and one of them need to end at the “Microsoft Code Verification Root”.
So why there is only one top level certificate in this case? note that i am not the one who signed this driver, it was included in another project that was sent to me.
How did the signer signed this driver that has caused this problem? i have never encountered this issue when i signed drivers myself using signtool.
If there is no cross-certificate chain, it means that the cross-certificate was probably not used when signing. For drivers one needs to use the /ac PATH_TO_CROSS argument of signtool to include it. The other person, who signed it, could have forgotten to add that argument, or used an expired cross-certificate and didn’t notice the warning message signtool produced. If this is what happened, the drivers need to be signed again, using the proper command and/or cross-cert. (I’m not sure if it’s possible to add a cross-certificate to an already signed file.)
In the past I had a very similar problem with a driver I’m maintaining myself.
Actually, when I signed the file, the cross cert was missing in the cert chain of signatures appended to the file.
Anyway, whenever I ran signtool on the development machine to check the cert chain, it returned “success”, telling that the driver was signed correctly. The reason was that the missing cross cert had been imported into the cert store, so signtool always found it there when I ran the check.
Only when I ran signtool on a different machine, where none of my certs were available in the cert store, I got an appropriate error telling that a cross cert was missing from the file.
Maybe the guy who signed the driver discussed in this thread encountered the same pitfall.
@CaptainFlint said:
If there is no cross-certificate chain, it means that the cross-certificate was probably not used when signing. For drivers one needs to use the /ac PATH_TO_CROSS argument of signtool to include it. The other person, who signed it, could have forgotten to add that argument, or used an expired cross-certificate and didn’t notice the warning message signtool produced. If this is what happened, the drivers need to be signed again, using the proper command and/or cross-cert. (I’m not sure if it’s possible to add a cross-certificate to an already signed file.)
@Martin_Burnicki said:
In the past I had a very similar problem with a driver I’m maintaining myself.
Actually, when I signed the file, the cross cert was missing in the cert chain of signatures appended to the file.
Anyway, whenever I ran signtool on the development machine to check the cert chain, it returned “success”, telling that the driver was signed correctly. The reason was that the missing cross cert had been imported into the cert store, so signtool always found it there when I ran the check.
Only when I ran signtool on a different machine, where none of my certs were available in the cert store, I got an appropriate error telling that a cross cert was missing from the file.
Maybe the guy who signed the driver discussed in this thread encountered the same pitfall.
I asked the guy who signed it, and he says that since its an EV certificate and he is using the token, there is no need to use the /ac option. i have never signed with an EV certificate, so is this correct?
This is the command that he is using to sign it :
signtool sign /a /tr http://rfc3161timestamp.globalsign.com/advanced /td SHA256 driver.sys
And i assume the timestamp server is not important, and he can use any timestamp server he wants, right?
I asked the guy who signed it, and he says that since its an EV certificate and he is using the token, there is no need to use the /ac option.
He is wrong. If you are signing a package to be submitted to Microsoft, then you do not need to cross-sign. But if you are self-signing this file for use on older systems or Win 10 systems without “Secure Boot”, then you absolutely do need to cross-sign.
And i assume the timestamp server is not important, and he can use any timestamp server he wants, right?
Right.
1 Like
@Tim_Roberts said:
I asked the guy who signed it, and he says that since its an EV certificate and he is using the token, there is no need to use the /ac option.
He is wrong. If you are signing a package to be submitted to Microsoft, then you do not need to cross-sign. But if you are self-signing this file for use on older systems or Win 10 systems without “Secure Boot”, then you absolutely do need to cross-sign.
And i assume the timestamp server is not important, and he can use any timestamp server he wants, right?
Right.
Yeah that makes sense.
So where can he download the proper cross certificate file for the /ac option? He says they never send him such a file when he purchased the certificate. The top most certificate in the certificate chain is “COMODO RSA Certification Authority”, but there is no such thing in the docs to download :
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing#cross-certificates-overview
And there is nothing in the sectigo website.
Right. It’s not provided with the cert… it’s provided by MSFT at that link you listed.
If there’s no valid cross cert available, then you can’t cross sign the driver. Not all certs or cert authorities are members of the MSFT Trusted Root program and thus not all have issued cross certs.
Peter