Opened 11 years ago
Closed 11 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 11 years ago by
comment:2 Changed 11 years ago by
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 11 years ago by
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 11 years ago by
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 11 years ago by
| Milestone: | release 2.3 |
|---|---|
| Priority: | blocker → minor |
comment:6 Changed 11 years ago by
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:
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!
comment:7 Changed 11 years ago by
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 11 years ago by
| 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 11 years ago by
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 11 years ago by
| Milestone: | release 2.3.3 → release 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 11 years ago by
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 11 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
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.
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:
Intermediate:
Entity: