Opened 7 years ago

Closed 7 years ago

#341 closed Bug / Defect (worksforme)

TAP-Windows installation failed, probably because of not trusted root certificate

Reported by: MiCRoPhoBIC Owned by:
Priority: minor Milestone: release 2.3.4
Component: Installation Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: tap, certificate, digicert, root, trust, chain, sign
Cc:

Description

I have tried to install the latest OpenVPN (openvpn-install-2.3.2-I003-i686.exe) on Windows 7 Professional (64bit) but it fails on the TAP-Windows step. I have tried to run manually the tap-windows install by getting the latest version from here:
http://build.openvpn.net/downloads/releases/tap-windows-9.9.2_3.exe
but the result was the same.

After observing the setupapi.dev.log it looks like there is some problem with verifying the certificate chain against the trusted root certificates.

>>>  [Device Install (UpdateDriverForPlugAndPlayDevices) - tap0901]
>>>  Section start 2013/10/21 12:16:28.272
      cmd: "C:\Program Files\TAP-Windows\bin\devcon.exe" install "C:\Program Files\TAP-Windows\driver\OemWin2k.inf" tap0901
     dvi: Set selected driver complete.
     dvi: {Build Driver List} 12:16:28.288
     cpy:      Policy is set to make all digital signatures equal.
     dvi:      Processing a single INF: 'c:\program files\tap-windows\driver\oemwin2k.inf'
     inf:      Opened INF: 'c:\program files\tap-windows\driver\oemwin2k.inf' ([strings])
     sig:      {_VERIFY_FILE_SIGNATURE} 12:16:28.288
     sig:           Key      = oemwin2k.inf
     sig:           FilePath = c:\program files\tap-windows\driver\oemwin2k.inf
     sig:           Catalog  = c:\program files\tap-windows\driver\tap0901.cat
!    sig:           Verifying file against specific (valid) catalog failed! (0x800b0109)
!    sig:           Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
     sig:      {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 12:16:28.397
     sig:      {_VERIFY_FILE_SIGNATURE} 12:16:28.397
     sig:           Key      = oemwin2k.inf
     sig:           FilePath = c:\program files\tap-windows\driver\oemwin2k.inf
     sig:           Catalog  = c:\program files\tap-windows\driver\tap0901.cat
     sig:           Success: File is signed in Authenticode(tm) catalog.
     sig:           Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.
     sig:      {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 12:16:28.412
     dvi:      Created Driver Node:
     dvi:           HardwareID   - tap0901
     dvi:           InfName      - c:\program files\tap-windows\driver\oemwin2k.inf
     dvi:           DevDesc      - TAP-Windows Adapter V9
     dvi:           DrvDesc      - TAP-Windows Adapter V9
     dvi:           Provider     - TAP-Windows Provider V9
     dvi:           Mfg          - TAP-Windows Provider V9
     dvi:           ModelsSec    - tap0901.NTamd64
     dvi:           InstallSec   - tap0901.ndi
     dvi:           ActualSec    - tap0901.ndi
     dvi:           Rank         - 0x00ff0000
     dvi:           Signer       - OpenVPN Technologies, Inc.
     dvi:           Signer Score - Authenticode
     dvi:           DrvDate      - 07/02/2012
     dvi:           Version      - 9.0.0.9

 ....cut....

     sto:                {DRIVERSTORE_IMPORT_NOTIFY_VALIDATE} 12:16:29.083
     inf:                     Opened INF: 'C:\Windows\System32\DriverStore\Temp\{153d22cc-b6c7-6407-819f-e253cc223d15}\oemwin2k.inf' ([strings])
     sig:                     {_VERIFY_FILE_SIGNATURE} 12:16:29.083
     sig:                          Key      = oemwin2k.inf
     sig:                          FilePath = C:\Windows\System32\DriverStore\Temp\{153d22cc-b6c7-6407-819f-e253cc223d15}\oemwin2k.inf
     sig:                          Catalog  = C:\Windows\System32\DriverStore\Temp\{153d22cc-b6c7-6407-819f-e253cc223d15}\tap0901.cat
!    sig:                          Verifying file against specific (valid) catalog failed! (0x800b0109)
!    sig:                          Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
     sig:                     {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 12:16:29.114
     sig:                     {_VERIFY_FILE_SIGNATURE} 12:16:29.114
     sig:                          Key      = oemwin2k.inf
     sig:                          FilePath = C:\Windows\System32\DriverStore\Temp\{153d22cc-b6c7-6407-819f-e253cc223d15}\oemwin2k.inf
     sig:                          Catalog  = C:\Windows\System32\DriverStore\Temp\{153d22cc-b6c7-6407-819f-e253cc223d15}\tap0901.cat
     sig:                          Success: File is signed in Authenticode(tm) catalog.
     sig:                          Error 0xe0000242: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.
     sig:                     {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 12:16:29.130
     sto:                     Validating driver package files against catalog 'tap0901.cat'.
!!!  sto:                     Driver package signer is unknown and user does not trust the signer.
!!!  ndv:                     Driver package failed signature validation. Error = 0xE0000243
     sto:                {DRIVERSTORE_IMPORT_NOTIFY_VALIDATE exit(0xe0000243)} 12:16:29.442
!!!  sto:                Driver package failed signature verification. Error = 0xE0000243
!!!  sto:                Failed to import driver package into Driver Store. Error = 0xE0000243
     sto:           {Stage Driver Package: exit(0xe0000243)} 12:16:29.442
!!!  sto:           Failed to stage driver package to Driver Store. Error = 0xE0000243, Time = 530 ms
     sto:      {Import Driver Package: exit(0xe0000243)} 12:16:30.097
     inf:      Opened INF: 'c:\program files\tap-windows\driver\oemwin2k.inf' ([strings])
!    inf:      Add to Driver Store unsuccessful
!    inf:      Error 0xe0000243: The publisher of an Authenticode(tm) signed catalog was not established as trusted.
!!!  inf:      returning failure to SetupCopyOEMInf
     inf: {SetupCopyOEMInf exit (0xe0000243)} 12:16:30.409
!!!  ndv: Driver Package import failed for new device...installing NULL driver.
!!!  ndv: Error 0xe0000243: The publisher of an Authenticode(tm) signed catalog was not established as trusted.
     dvi: {Plug and Play Service: Device Install for ROOT\NET\0000}
     ump:      Creating Install Process: DrvInst.exe 12:16:30.425
!    ndv:      Installing NULL driver!
     dvi:      Set selected driver complete.
 
 ....cut....

     dvi:           CoInstaller 1: Enter 12:16:30.456
!!!  cci:                NdisCoinst: NcipOpenDriverRegistryKey failed with error code 0xe0000204
     cci:                NdisCoinst: Null driver install
     dvi:           CoInstaller 1: Exit
     dvi:           CoInstaller 2: Enter 12:16:30.456
     dvi:           CoInstaller 2: Exit
     dvi:           CoInstaller 3: Enter 12:16:30.456
     dvi:           CoInstaller 3: Exit
     dvi:           Class installer: Enter 12:16:30.456
     cci:                [NCI BEGIN INSTALL DEVICE for ROOT\NET\0000]
     cci:                NCI: Null driver install.
     cci:                [NCI END INSTALL DEVICE for ROOT\NET\0000]
     dvi:           Class installer: Exit
     dvi:           Default installer: Enter 12:16:30.456
!    dvi:                Installing NULL driver!
!    dvi:                A NULL driver installation is not allowed for this type of device!
!!!  dvi:                Cleaning up failed installation (e0000219)
!!!  dvi:           Default installer: failed!
!!!  dvi:           Error 0xe0000219: The installation failed because a function driver was not specified for this device instance. 

When I have checked what is the chain and why it failed, by looking at certification chain of tap0901.cat:

Digicert -> Digicert High Assurance Code Signing CA-1 -> OpenVPN Technologies, Inc.

I wanted to compare the Serial Numbers and Thumbprints of the Digicert root and intermediate certificates, but I found that only the root certificate with such numbers exists on Digicert's website. The Intermediate one I did not found!

TAP-Windows tap0901.cat file signature:

Digicert High Assurane EV Root CA:
Valid from: 11/10/2006 to 11/10/2031
Serial: 02:AC:5C:26:6A:0B:40:9B:8F:0B:79:F2:AE:46:25:77
Thumbprint: 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25

The Root of the chain looks fine, comparing it to Digicert's website:
https://www.digicert.com/digicert-root-certificates.htm

But the intermediate one IS NOT:

DigiCert High Assurance Code Signing CA-1
Valid from:  
Serial: 02:C4:D1:E5:8A:4A:68:0C:56:8D:A3:04:7E:7E:4D:5F
Thumbprint:E3:08:F8:29:DC:77:E8:0A:F1:5E:DD:41:51:EA:47:C5:93:99:AB:46

Can't find such certificate on their website:
https://www.digicert.com/digicert-root-certificates.htm

It is very suspicious, because the "Valid from" and "Valid to" dates
are the same, but the used certificate and the one in Digicerts website are having different Serial numbers and Thumbprints.

It is even creepier when you search for the Thumbprint E308F829DC77E80AF15EDD4151EA47C59399AB46 in Google... the only results are from virustotal scan reports.

I know about the bug with the expired signature (https://community.openvpn.net/openvpn/ticket/321) and I guess that's why it has new signature from August 2013, but I think something is wrong with the chain of trust or maybe with the auto distribution of Root CA of Windows 7? Or compromised certificate, god forbid ;-)

Change History (12)

comment:1 Changed 7 years ago by JoshC

The cert chain appears to be completely valid. If you extract the "drivers" dir from the tap-installer.exe (which has md5sum ac9b2624ef366742c9ad32b86225a251, plus a gpg signature with all official releases) the cat file shows the cert chain.

If you extract both the entity cert saved as "cat.cer" and the intermediate cert saved as "intermediate.cer", you can use openssl to verify the chain. I pulled the CA cert out of the Windows cert manager, since the OS will consult its trusted roots to get a full cert chain. This is called "DigiCert? High Assurance EV Root CA" in your cert manager, with:

SHA1 Fingerprint=5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25

I extracted this CA cert and called it "digicert-ca.cer"

With all 3 certs saved, use openssl to verify the cert chain against your OS-trusted root:

openssl verify -verbose -CAfile digicert-ca.cer -untrusted intermediate.cer cat.cer
cat.cer: OK

Everything looks file. You won't find the intermediates listed on a CA's list of root certificates; intermediates are not roots, but are issued by roots. The entity will include these in a bundle presented to clients that verify them.

For reference, these are the certs along with their Subject, Validity, and fingerprint output:

CA:

Issuer: C=US, O=DigiCert? Inc, OU=www.digicert.com, CN=DigiCert? High Assurance EV Root CA
Validity

Not Before: Nov 10 00:00:00 2006 GMT
Not After : Nov 10 00:00:00 2031 GMT

Subject: C=US, O=DigiCert? Inc, OU=www.digicert.com, CN=DigiCert? High Assurance EV Root CA

SHA1 Fingerprint=5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25

Intermediate:

Issuer: C=US, O=DigiCert? Inc, OU=www.digicert.com, CN=DigiCert? High Assurance EV Root CA
Validity

Not Before: Feb 11 12:00:00 2011 GMT
Not After : Feb 10 12:00:00 2026 GMT

Subject: C=US, O=DigiCert? Inc, OU=www.digicert.com, CN=DigiCert? High Assurance Code Signing CA-1

SHA1 Fingerprint=E3:08:F8:29:DC:77:E8:0A:F1:5E:DD:41:51:EA:47:C5:93:99:AB:46

Entity:

Issuer: C=US, O=DigiCert? Inc, OU=www.digicert.com, CN=DigiCert? High Assurance Code Signing CA-1
Validity

Not Before: Aug 13 00:00:00 2013 GMT
Not After : Sep 2 12:00:00 2016 GMT

Subject: C=US, ST=California, L=Pleasanton, O=OpenVPN Technologies, Inc., CN=OpenVPN Technologies, Inc.

SHA1 Fingerprint=EC:4F:1D:31:68:66:25:EC:C0:04:99:3C:D0:E8:9A:41:36:DD:33:44

comment:2 Changed 7 years ago by MiCRoPhoBIC

Checked the checksum of the file - it is valid and same as yours.
I have extracted the certificates from Windows certmgr, and .inf file and have checked the
chain by openssl. It is valid as you said.
Still I cannot explain if the root is in Windows cert store, the chain is valid, why the installation is failing with reason:

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

Btw. On the Digicert's website (https://www.digicert.com/digicert-root-certificates.htm)
there is a list of root certificates AND intermediate certificates:

"Intermediate Certificates
Below are links to DigiCert intermediate certificates"

The one that OpenVPN is using with fingerprint:

SHA1 Fingerprint=E3:08:F8:29:DC:77:E8:0A:F1:5E:DD:41:51:EA:47:C5:93:99:AB:46

is not listed there. I'm not sure if this is normal.
Do they list only SOME of the intermediate certificates and not all?

comment:3 Changed 7 years ago by MiCRoPhoBIC

Hm, I have tried many things (observing certificate chain, Public key polcy settings, refreshing the list of Trusted Root CA's), but it looks like the only way to install successfully tap-windows-9.9.2_3.exe was to import the OpenVPN certificate used to sign the package

(with SHA1 Fingerprint=EC:4F:1D:31:68:66:25:EC:C0:04:99:3C:D0:E8:9A:41:36:DD:33:44)

in Windows Certificate Store using (mmc.exe's add/remove snap-in). It only worked if it is imported in "Trusted Publishers" section of "Certificates - Local Computer". It doesn't work if imported in "Certificates - Current User".

After this step, the tap-windows can be successfully installed. Still, the install logs
are showing the error (Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.) :
http://pastebin.com/RZWjnMa4

Also, testing the signatures of the .cat/.sys files with signtool's verify option (this tool is from Microsoft Windows SDK 7.1) still failed, but the install works, so I can use OpenVPN!
Still not sure what is the root of the problem, but for now I have a workaround.

comment:4 Changed 7 years ago by Samuli Seppänen

This looks like some odd corner-case. If someone else is experiencing this issue please let us know - otherwise we'll have to close the bug report as "worksforme".

comment:5 Changed 7 years ago by Samuli Seppänen

Milestone: release 2.3
Priority: blockerminor

comment:6 Changed 7 years ago by cml37

Don't close it! Having a similar problem, except that I can't install the drivers AT ALL!

Salient parts of setupapi.dev.log:

     dvi:                     Default installer: Exit
     dvi:                {DIF_INSTALLDEVICEFILES - exit(0x00000000)} 15:49:54.373
     flq:                File 'C:\WINDOWS\system32\DRIVERS\tap0901.sys' pruned from copy.
!    sig:                VerifyTrustFailed for C:\WINDOWS\system32\DRIVERS\tap0901.sys.
!    sig:                Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
     dvi:                {DIF_REGISTER_COINSTALLERS} 15:49:54.450

Installed certificates like suggested above by the user in the bug report. Here's a screenshot of my Certificates snap in:
http://lenderman.com/certificate2.png

So, for me this is a BLOCKER! Please let me know if there's anything you'd like me to try or do to help further diagnose. Thanks!

Last edited 7 years ago by cml37 (previous) (diff)

comment:7 Changed 7 years ago by cml37

I'm starting to think this is a symptom and not a problem in my case. I may be experiencing some other incompatibility issue.

comment:8 Changed 7 years ago by Gert Döring

Milestone: release 2.3.3

So what is the state of things here? Do we need to fix something for 2.3.3, or is everything good now?

I remeber we had a discussion about expired certs, but as far as I know, everything was fixed.

I put this on milestone 2.3.3 so we'll re-check it, but if nobody complains until March 1, I'll close it.

comment:9 Changed 7 years ago by MiCRoPhoBIC

I think that cml37 is right, it looks more like a sympthom of something else gone wrong, rather than a problem/bug in the TAP driver itself. Until now I only had two computers with such effect and successfully installed at least 2-3 other after this case with the same installer without problems. Still I don't know what was the reason for this problem.

comment:10 Changed 7 years ago by Gert Döring

Milestone: release 2.3.3release 2.3.4

Since we've now done two new 2.3.2-I004 and 2.3.3-I001 windows installer releases - could you please re-test whether this is still an issue? Otherwise I'd like to close this...

comment:11 Changed 7 years ago by MiCRoPhoBIC

Unfortunately I don't have access to the two computers with the problem anymore, so I can't test them with the new releases. I think it is perfectly OK to close the bug for now.For me it didn't happened on any other PCs installations after, so maybe it isn't TAP driver's fault really.

comment:12 Changed 7 years ago by Gert Döring

Resolution: worksforme
Status: newclosed

Thanks. I'm closing this now, but will keep in mind that there have been "unclear issues" with the TAP driver signature - and if it happens again, maybe it will be helpful to correlate.

Note: See TracTickets for help on using tickets.