Npcap OEM 0.9990: Driver install warning/prompt on WS2008R2; silent install fails #107
Comments
akontsevoy
changed the title
|
Thanks for reporting this. We've been working with 2 separate private reports of this happening on Windows Server 2012 and Windows 7. The timestamp signature is an interesting idea we had not looked into. We're trying with the next installer to bundle all certs in the chain and install those before trying to install the driver, though as you pointed out, the error still happens on systems where the certificate chain is valid according to I notice that even Npcap 0.9984 has a minor error regarding a signature that doesn't terminate in a trusted root. I will try looking into that, too. Our long-term plan is to pursue WHQL certification so that Microsoft signs off on our drivers and we don't have to worry about certificate chains any more. This is especially important since Server 2016 does not work with attestation-signed drivers any more (which is what we have been using for Windows 10-based systems). |
|
Speaking of WHQL, I was wondering why your Win10 drivers are counter-signed by Microsoft but their Win7/8 versions are not. I thought they are otherwise the same drivers. |
|
The counter-signature for Win10 is an "attestation signature," which is not trusted by Windows versions prior to Windows 10. Similarly, Windows 10 does not trust non-Microsoft-signed drivers without significant security modifications that we will of course not perform in our installer. They are the same drivers down to the byte at the moment, but we are investigating supporting more recent NDIS versions for the Windows 10 driver since it needs to be shipped separately anyway. |
|
Npcap 0.9991 is signed with a certificate from a different issuer, as well as a secondary SHA-1 signature. This has worked on these platforms in the past, so we believe Npcap 0.9991 will solve this problem. Please let us know so we can close this issue. |
|
@dmiller-nmap This is still not fixed as of 0.9991. In fact, the install now fails the same way on any Windows version below W10/WS2016. This is because npcap.cat is signed with a SHA1 certificate, but only SHA2 certificate is installed into the Trusted Publishers store. Manually installing the SHA1 certificate into the said store works around the problem (including WS2008R2). |
|
Thanks for everyone's comments. This should be fixed in 0.9994 so I'm closing the issue. But please comment and re-open if anyone finds it not fixed for them. |
Greetings,
On a fully patched Windows Server 2008 R2 x64 (including the all-important SHA2 patch, KB3033929), I am still getting failures of silent installation thanks to "untrusted" drivers. Comodo's CA certs are added to Windows trusted root and intermediate cert stores, and Insecure.com LLC certificate is added to the trusted publishers store. Npcap 0.9984 (the last version signed by DigiCert, as opposed to Comodo) does not suffer from this problem. The below logs indicate that Windows can't build the certificate chain up to a trusted root (which is, for kernel drivers, apparently only "Microsoft Code Verification Root"). But I can't seem to find any fault with the driver package; its npcap.cat seems to include all intermediate certificates, including COMODO RSA Certification Authority cross-signed by Microsoft Code Verification Root. What's worse, signtool.exe /kp validates the package just fine on the target system!
Note that the prompt is different than an unsigned driver prompt that you'd see on Windows Server 2008 (non-R2) which does not support SHA2 signatures.
Contents of NPFInstall.log:
Contents of SetupAPI.dev.log:
Contents of SetupAPI.dev.log with version 0.9984 on the same system:
Output of
signtool.exe verify /kp /v npcap.cat(0.9990):Output of
signtool.exe verify /kp /v npcap.cat(0.9984):I can't seem to find any fault with 0.9990 as opposed to 0.9984, other than that it's signed by a different CA and uses SHA256 to sign (rather than SHA1) -- but in theory this should not matter. Perhaps it's the fact that the signing certificate is by Comodo, but the timestamp signature is still by DigiCert? Perhaps it should be switched to Comodo as well, per instructions at https://support.comodoca.com/Com_KnowledgeDetailPageSectigo?Id=kA01N000000zFK6 ?
The text was updated successfully, but these errors were encountered: