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

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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/


Production signing driver in Visual Studio 2019

h7rh7r Member Posts: 3

Hello all,

after some time I turned back to driver writing and got stuck with all this modern driver signing stuff.

I have an NDIS filter driver that follows the WDK example from a couple of years ago (Visual Studio 2013 at that time) that I moved to Visual Studio 2019, mainly because my OV code signing certificate from a couple of years ago finally expired. So I bought an USB token based EV code signing certificate from Sectigo (which turned out to still be issued by Comodo CA) besides another plain old OV certificate (which really is Sectigo issued).

I can nicely sign normal programs via signtool with both certificates, but I'm completely lost signing my filter driver in Visual Studio 2019 (no signtool build-step). Regardless which of the certificates I choose (the EV or the OV) I get the message "error : No matching cross certificate found for the given production signing certificate.". For the OV certificate all the Sectigo intermediate certificates are installed and located in my certificate store (both current user and local system) while for the EV certificate "COMODO RSA Extended Validation Code Signing CA" is missing and I also didn't find it on the web (asked Sectigo about that).

Some details: The project already in the VS2013 incarnation had configurations for W7, W8 and W8.1. After updating it to VS2019 I added a W10 configuration and changed the respective settings. All configurations compile and link. In the project settings under "Driver Signing" on the "General" tab the W7, W8 and W8.1 configurations don't have a parameter "Cross-Signing Certificate", while the W10 configuration has. What do I have to enter there?

Besides the fact that the production-signed driver afterwards has to be sent to MS (thanks for all the blog posts regarding Attestation Signing) how is driver signing inside Visual Studio 2019 meant to be working. Shouldn't it even being possible to sign with a plain old OV certificate?

And something else puzzled me: In the project settings under "Driver Signing" on the "General" tab for the parameter "TimeStampServer" I can only choose from "Verisign", "Globalsign" or "none", nada "Sectigo" (resp. "Comodo"). Bought the wrong certificate?

Any hints very much appreciated!

PS: Please forgive my ignorance. Driver writing/signing isn't my daily business at all and sometimes I feel the world is moving too fast :-)

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,886

    For production signing, just sign your driver and your CAT file with your EV cert using signtool and submit it to MSFT for attestation signing, and you’ll be good to go for Win10.

    Read about crosss-signing here.
    You can any time stamp server... you can use the verisign one even if you another cert.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,483

    Just for the sake of completeness, you don't actually have to sign your driver or your CAT file before submitting it for attestation signing. You just have to sign the cabinet. In fact, you don't have to include a CAT file at all; Microsoft will just throw yours out and create a new one from scratch.

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

  • h7rh7r Member Posts: 3

    Hi Peter and Tim et al,

    thank you so much for your help.

    When studying the above link (and many other articles in the web), I was a bit disenchanted with my choice of certificate, because on the MS cross-certificate page neither Comodo nor Sectigo are listed. So I thought I need another certificate of one of the listed companies.

    Anyhow yesterday I then completely disabled code signing the VS2019 way and did it by signtool as a post-build step (cat and sys). That worked like a charm (but also made the "package" project in the solution obsolete).

    Then I stumbled upon a digicert article where kernel mode code signing with signtool and how to check for a valid certificate of a binary was explained. So I found out that in my driver the Microsoft root was missing and it didn't fulfil the WIndows 10 x64 requirments. With another search on the web I found a Comodo page that offered a cross-certificate to download and with that and the /ac switch in signtool I could correctly sign.

    Now the next step is creating a cabinet and submitting to MS. Gonna reread Peter's blog article about attestation signing.

    Thanks again!!!

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,886

    Just to be clear: You don’t need to cross-sign for Win10... you need to attestation sign. In fact, as Mr. Roberts indicated for Win10 you don’t technically have to sign at all.

    In terms of production signing with VS, we don’t use it either. We sign with signtool... much easier in the end.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • h7rh7r Member Posts: 3

    Thanks again. Very much appreciated.

    Well if I don't sign at all for attestation signing:
    What certificate will the driver(s) returned from Microsoft carry? Will these then be signed "Microsoft Corp." or "Microsoft"?

    If so, was buying a not so cheap EV code signing certificate then useless? because for signing programs it wouldn't be necessary. suffices an OV certificate.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,483

    Will these then be signed "Microsoft Corp." or "Microsoft"?

    Who cares? As long as the certificate is recognized by Windows, that's all you need. The certificate they use does not change based upon what you submit. Remember, they (1) throw away your CAT and create a new one, and (2) add their certificate to all the executable files in your package. That's all they do. It's a simple process.

    Your certificate serves two uses. One, you can use it to sign and cross sign packages for older systems, and for Win 10 systems without "secure boot". This is the path that is supposedly disappearing. Two, you can use it to establish your dashboard account, and to sign cabinet files that are submitted for WHQL signing and attestation signing.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,886

    was buying a not so cheap EV code signing certificate then useless

    Dude... did you **read **my blog post(s) that you referenced or not?

    You need an EV Cert to create a dashboard account. You need a dashboard account to get your driver Attestation Signed.

    to quote my blog post:

    Sooooo…

    • Get your company an EV Cert. I know it’s unreasonably expensive, but just grimace and pay the ridiculous price, it’s not your money and there’s no other alternative.
    • Using the EV Cert, sign-up for an account on the Microsoft Hardware Dev Center. This will require that you claim to have read and agree to a pile of documents, and that you sign a dummy file with your very expensive EV Cert and upload it.
    • Take your driver package and create a CAB file out of it.
    • Sign into the Microsoft Hardware Dev Center, indicate that you want to make an Attestation Signing submission, and then drag and drop your CAB file into the portal.
    • Wait a bit.
    • Download the signed package containing your signed executable.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA