EV certificate cannot be selected for production certificate

We were issued a code signing ev cert from ssl.com. It is on a usb token. Now trying to use it from vs2019’s Driver Signing window. The ev cert shows up in when pressing the Select from Store button for the test certificate. However, when pressing the Select from Store button for the production certificate it does not show up. Any idea what might cause this?

I suggest you try to edit the vcxproj itself. I add this section by hand (but then, I do all my vcxproj files by hand):

  <PropertyGroup>
    <!-- This must follow Microsoft.cpp.props.  Otherwise the disable gets overwritten. -->
    <SignMode>ProductionSign</SignMode>
    <SubjectName>Providenza & Boekelheide, Inc.</SubjectName>
    <DisableProductionSignDebugWarnings>true</DisableProductionSignDebugWarnings>
    <ProductionCertificate>eb41c746f86b7b382a1813fe0423cc113f8bc89e</ProductionCertificate>
    <TimestampServer>http://timestamp.digicert.com/scripts/timestamp.dll</TimestampServer>
  </PropertyGroup>

What i tried that seemed a bit safer was to select test signing and use the ev cert However, when submitting the cab file the microsoft dashboard it gets rejected with this error:

“For a Windows 10 submission, the input package and the included files must be signed with sha256 signature algorithm.”

The cab contains an inf file, cat file, sys file. The cat, sys & cab are all sha256 signed with the ev cert (/fd sha256 option). Here is signtool output:

“c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\signtool” verify /v driver.cab

Verifying: driver.cab

Signature Index: 0 (Primary Signature)
Hash of file (sha256): 93E716A2A4C495E71A1EE91644D0E81EB972A56E49E801B3F23BEE6F87F7BF3B

Signing Certificate Chain:
Issued to: SSL.com EV Root Certification Authority ECC
Issued by: SSL.com EV Root Certification Authority ECC
Expires: Wed Feb 13 01:15:23 2041
SHA1 hash: 4CDD51A3D1F5203214B0C6C532230391C746426D

    Issued to: SSL.com EV Code Signing Intermediate CA ECC R2
    Issued by: SSL.com EV Root Certification Authority ECC
    Expires:   Sat Mar 04 02:37:45 2034
    SHA1 hash: 7DC509CC760F073EE038040507C27858402D3B19

        Issued to: ------------------------------
        Issued by: SSL.com EV Code Signing Intermediate CA ECC R2
        Expires:   Mon Jun 03 02:33:28 2024
        SHA1 hash: 18EFC429FA481E883634B62F42A26EE7F2839CB4

File is not timestamped.

SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.

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

Well, for one thing, it doesn’t look like the files were cross-signed.

I suggest that you just sign whatever you need signed yourself, using Signtool… that’s what we do. I’ve never used the “production sign” thing in VS. Why automate a step that requires you plug in a smart card, and enter a password… you know?

Peter

Is the cert an DHA2 cert, and are root cetts SHA2?
That is not the same aa FD switch.

Kind regards, Dejan.
https://www.alfasp.com

I suggest…using Signtool

Tried that–no effect.

it doesn’t look like the files were cross-signed

Is this required and if so how can this be achieved?

Is the cert an SHA2 cert, and are root certs SHA2?

How can I verify this?

Yes. Cross signing is required.

Google how to sign kernel mode drivers for Windows. If you don’t do that, how could you possibly know which options to use for signtool? Maybe you can start with this.

Peter

Yes. Cross signing is required.

It is required if you plan to load your self-signed driver package onto a non-secure-boot system. It’s not required if you’re just signing a cabinet for submission to the hardware dashboard.

Describing the signing situation is like writing a C function with 15 if/elseif/elseif clauses. I’ve delivered a 3-page white paper to several clients already.

1 Like

To cap this thread. After all this time SSL.COM has finally confirmed to us their ev certs don’t work for driver signing. While a SHA256 algorithm can be selected, they also contain a SHA384 signature which is incompatible with both the hardware dashboard and vs2019. Recommend staying away from this company not only due to selling a product for a particular use that doesn’t work, but also never testing their own product, refusing to test their own product after a customer discovers a problem, and overall very slow and unhelpful support. It’s actually taken months to get the the status of everyone agreeing “it doesn’t work” and that only happened because we contacted Microsoft directly to lean on them because before that ssl told us it’s YOUR problem and refused to do anything. It is as of now unclear if SSL.COM can ever make an ev cert that will work with drivers and how many months more this might take, if ever.

I had read archived threads that it doesn’t matter who you get your cert from because they all work the same. Well it does matter. It is puzzling that SSL.COM is listed as one of 6 approved vendors for driver ev certificates on the Microsoft web site, so be extra aware their certificates do not work for drivers and their support is horrible.

@Lakelands said:
To cap this thread. After all this time SSL.COM has finally confirmed to us their ev certs don’t work for driver signing. While a SHA256 algorithm can be selected, they also contain a SHA384 signature which is incompatible with both the hardware dashboard and vs2019. Recommend staying away from this company not only due to selling a product for a particular use that doesn’t work, but also never testing their own product, refusing to test their own product after a customer discovers a problem, and overall very slow and unhelpful support. It’s actually taken months to get the the status of everyone agreeing “it doesn’t work” and that only happened because we contacted Microsoft directly to lean on them because before that ssl told us it’s YOUR problem and refused to do anything. It is as of now unclear if SSL.COM can ever make an ev cert that will work with drivers and how many months more this might take, if ever.

I had read archived threads that it doesn’t matter who you get your cert from because they all work the same. Well it does matter. It is puzzling that SSL.COM is listed as one of 6 approved vendors for driver ev certificates on the Microsoft web site, so be extra aware their certificates do not work for drivers and their support is horrible.

SHA384 is now an industry standard and not just a SSL.com problem (https://knowledge.digicert.com/alerts/code-signing-new-minimum-rsa-keysize.html). Yes this means all you DigiCert customers (I was a previous one) will have this issue too unless Microsoft fixes Partner Center. This is Microsoft’s F-UP full stop.

@Lakelands said:
To cap this thread. After all this time SSL.COM has finally confirmed to us their ev certs don’t work for driver signing. While a SHA256 algorithm can be selected, they also contain a SHA384 signature which is incompatible with both the hardware dashboard and vs2019. Recommend staying away from this company not only due to selling a product for a particular use that doesn’t work, but also never testing their own product, refusing to test their own product after a customer discovers a problem, and overall very slow and unhelpful support. It’s actually taken months to get the the status of everyone agreeing “it doesn’t work” and that only happened because we contacted Microsoft directly to lean on them because before that ssl told us it’s YOUR problem and refused to do anything. It is as of now unclear if SSL.COM can ever make an ev cert that will work with drivers and how many months more this might take, if ever.

I had read archived threads that it doesn’t matter who you get your cert from because they all work the same. Well it does matter. It is puzzling that SSL.COM is listed as one of 6 approved vendors for driver ev certificates on the Microsoft web site, so be extra aware their certificates do not work for drivers and their support is horrible.

I have exactly the same problem. SSL were helpful and also claimed that other CAs were experiencing this issue and that their engineers were working with Microsoft to fix the problem.

However, in the meantime, we cannot get our submissions signed.

I was contacted by SSL and there appears to be an intermediary fix agreed with Microsoft in terms of a der file with sha256 algorithm.

1 Like