My EV code signing cert expired about a week ago. It used a Digicert hardware token (USB SafeNet device) that I had used for many years without issue. In a Visual Studio driver project you could select “Production Sign” and then in the Production Certificate field you could pick “Select from Store…” and it would show my cert as an option.
With this new EV CS cert issued last week (on a new hardware token which can handle RSA 4096-bit since the old token could only do 2048), Visual Studio no longer shows the option under Production Certificate. Select from store… gives no options now. If, however, I pick “test signing” and then pick Select from store… in the Test Certificate field, then it shows my new cert. Test signing, to my understanding, is for those bogus certs you create yourself, not something I associate with making a customer release.
Next I tried to copy the cert subject and thumbprint data from the test certificate field to the production certificate field and changed the type to Production Sign. I figured even if it wouldn’t let me select it, if I described it then it should be able to find it. (Signtool.exe at the command line was able to find it with just the thumbprint). But now VS complains that it needs a cross-signing cert. That’s bogus, those stopped being used for driver signing a couple years ago.
In the end, I was able to use the Test Signing option and then submit to the MSFT portal and produce an attestation package. But it just doesn’t seem quite right, and it’s certainly different from how it has been, so I wondered if anyone else had hit this.
The other thing, even though it seems to have worked, the returned binary from MSFT has two signatures - mine and theirs - but only theirs has a timestamp. It doesn’t seem that VS is using the DigiCert timestamp url with the test sign option.
Test signing, to my understanding, is for those bogus certs you create yourself, not something I associate with making a customer release.
It’s basically the same. You can’t do a customer release using “production signing” either. You HAVE to go through attestation signing. The only purpose for your certificate is to sign the cabinet that you send to the Hardware Dashboard.
Test signing, to my understanding, is for those bogus certs you create yourself, not something I associate with making a customer release.
It’s basically the same. You can’t do a customer release using “production signing” either. You HAVE to go through attestation signing. The only purpose for your certificate is to sign the cabinet that you send to the Hardware Dashboard.
Thanks for the reply, Tim. I know the attestation (or HLK) signing is a requirement for running on end user machines, but you don’t sign the .sys with your cert as well? I’ve always signed the .sys, generated the .cat, then signed the .cat, then created the .cab, then signed the .cab, then ran it through portal. This results in getting a driver back from MSFT which has both my cert and their cert on the .sys.
Many people do, but you do not actually have to sign anything except the .cab. It’s OK to sign the sys, but Microsoft throws away your cat file entirely and builds a new one from scratch, so there’s no point signing it. I don’t think you even need to include one, but it’s been a while, so I’ve forgotten.
Very interesting. I just confirmed that it works as you said, the cab contents don’t need any signatures. This contradicts my understanding of what attestation signing was all about in the first place. I always interpreted the dual signatures to effectively say “the first sig says I wrote this and the second sig says Microsoft confirms it.” It seems odd for a 3rd party to be able to ship out a driver which could have no identifying publisher info other than a Microsoft signature. I would assert this makes it look like Microsoft is the publisher.
In any case, thanks for that bit of enlightenment.
@Tim_Roberts said:
Many people do, but you do not actually have to sign anything except the .cab. It’s OK to sign the sys, but Microsoft throws away your cat file entirely and builds a new one from scratch, so there’s no point signing it. I don’t think you even need to include one, but it’s been a while, so I’ve forgotten.
It throws away the .cat file and the .pdb file. So I always store the .pdb file separately just in case.
Same issue as Jason has here. Got a new token for the new RSA 4096bit EV Codesigning Certificate. It’s only visible in the test signing store. No timestamp either but VS2022 clearly says the timestamp server is for production signing only.
For the record: We did not sing any driver files, only the .cab file. The driver files included were the .inf, .sys and .pdb files. In the dashboard it is still scanning the .cab file after 12 hours. Tried it again, also still scanning.
Next we test signed the driver (via VS2022) and submitted the .cab, et voila it worked, driver is attestation signed. So it seems to matter if you sign your .sys file!
Finally to re-ask Jasons question:
Does it matter that only the MS certificate is time stamped?
Or in other words:
Is the driver file still valid when our certificate expires (and our certificate is not time stamped)?
Is the driver file still valid when our certificate expires (and our certificate is not time stamped)?
It’s not the certificate that gets timestamped, it’s the signature in that specific file. And since timestamping is free, why wouldn’t you do it every single time? I certainly do.
Your question is an interesting one that I’ve never explored. If the .sys has a different signature from the .cab, does the kernel checker check them both, or does it stop looking after it find a signature in the .sys?
And since timestamping is free, why wouldn’t you do it every single time? I certainly do.
You can’t timestamp in VS when building a release driver because you can’t select the new EV certificate from the production store any more (that was the initial post here). Hence you can use for a release build in VS only Test-Sign with the new EV certificate where timestamping is not supported by VS.
(You can of course don’t sign at all in VS. Then sign and timestamp the .sys file from the command line with signtool with a Post-Build Event in VS.)
If the .sys has a different signature from the .cab, does the kernel checker check them both, or does it stop looking after it find a signature in the .sys?
I think there is a misunderstanding as you don’t ship the .cab to the customers.
When submitting the .cab to the MS portal we didn’t sign the driver at all, only the .cab file. This doesn’t work, after 24 hours it’s still pending at the scanning stage in the portal.
Next we EV signed the driver without timestamp (via VS Test-Sign) and then EV signed the .cab with the same EV certificate via signtool at the command line, this worked in the MS portal.
The question here is: Since the final .sys file has two signatures (our EV signature without timestamp and the MS signature with timestamp), will the driver still work if our certificate expires?
Which cert is first? For Server 2012 the timestamped signature must be the
first one.
If MS signature is first, your timestamp does not matter for now (meaning
unless MS changes some rules).
Our certificate is first (according to the Properties / Digital Signatures tab). At the end it doesn’t really matter because there is a surprising update:
After about 36 hours, both attempts of our unsigned drivers have finally been signed by MS. There might have been a glitch in their system (or it might be that our new certificate had never been used before, who knows).
In addition we added automated driver signing via signtool as Post-Build Event to VS release build.
So there is a choice not to sign at all or sign and timestamp after the release build.
It still remains a bug that our new RSA 4096bit EV Certificate can be used as a production certificate in VS2022.
You can’t timestamp in VS when building a release driver …
Oh, of course you can. The UI doesn’t have a way to select it, but it’s a trivial edit to your vcxproj file to enable this.
I think there is a misunderstanding as you don’t ship the .cab to the customers
You are, of course, right. What I meant was the .cat file, which IS shipped to customers, and is stored in the DriverStore along with the whole package.
Oh, of course you can. The UI doesn’t have a way to select it, but it’s a trivial edit to your vcxproj file to enable this.
Thanks for this hint, however it turns out you can do it in the VS UI.
To enable timestamping for a Test-Build:
Open Project Properties.
Select Driver Signing > Command Line
At the bottom at Additional Options add either: /tr http://timestamp.digicert.com /td sha256 /tr $(TimeStampServer) /td sha256