New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installer for 9.22.1 throws a signature error. #49
Comments
Hi,
On Wed, Apr 25, 2018 at 01:44:30PM +0000, crkinard wrote:
After installing 9.22.1 the adapter in device manager throws the following error.
> Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)
Which platform is this? Windows XP, Vista, ...? Fully patched?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
Updated the initial post. Two machines. The enterprise one is updated fully to WSUS settings so it MIGHT be missing something. I have a third I can try it on at home but its the same install as the pro machine and fully updated. Reloaded both pro machines in the last day so little is on them at the moment. |
Win10 should certainly work (and did, in our tests). We expected failures on old Win7 installs (due to SHA2 signatures not being supported yet), and Vista (for the same reasons). |
just an idea (will have a look myself later) ...
do we have a manifest on tap installer ?
2018-04-25 18:48 GMT+05:00 Gert Doering <notifications@github.com>:
… Hi,
On Wed, Apr 25, 2018 at 01:44:30PM +0000, crkinard wrote:
> After installing 9.22.1 the adapter in device manager throws the
following error.
>
> > Windows cannot verify the digital signature for the drivers required
for this device. A recent hardware or software change might have installed
a file that is signed incorrectly or damaged, or that might be malicious
software from an unknown source. (Code 52)
Which platform is this? Windows XP, Vista, ...? Fully patched?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never
doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACHVUNpTsYlEyRHrO2XMZjkJnlEQQQhcks5tsH6ogaJpZM4Tjc9c>
.
|
Win 10 Build 17134 same Problem. |
Please copy and paste the relevant part of C:\Windows\inf\setupapi.dev.log here. That will give more clues about the signature error. |
Emptied the file and re-ran the installer. I think this is what you need. |
@crkinard can you confirm that the problem is not present in tap-windows-9.21.2.exe? Also please post setupapi.dev.log for that one here so that we can have a look at the difference. |
2.21.2 worked. EDIT: Never mind what I had here last. I'm a gord. Didnt restart the service for OpenVPN that handles running admin level tasks after installing 2.21.2 |
I will have a look at the setupapi.dev.log files tomorrow morning if all goes well. |
I can confirm the same signature problem for 9.22.1 for Win 10 Pro 1709 (Build 16299.402). |
I have this problem too. OS Name: Windows 10 Enterprise 2016 LTSB Version 9.22.1 fails with 9.22.1 install log:
9.21.2 install log:
|
The root of the problem is this:
Can you check if the driver is present in the device drivers dialog in the Windows control panel? I think it should be there, but probably shows an exclamation mark. In other words, it has been installed successfully, but the kernel refuses to load it. |
That is exactly how it is. Shows up in device manager with a driver but refuses to load it because of bad signing. |
As a short-term workaround I built new Windows installer which include the old (9.21.2) tap-windows6 driver: Out of curiosity I will try to follow the exact same signing process as for 9.21.2 (dual signatures) to see if that makes any difference. If not, then I will go the hardware dev portal route. |
Can you try out this installer and see if it works? |
It is not dual-signed (don't have the SHA1 key). But the driver file itself (tap0901.sys) now has a signature. Previously only the security catalog (tap0901.cat) had it. |
same problem here on a fresh w10pro install. tested: the new linked "tap-windows-9.22.1-I602.exe" still throws error 52 signature problem in device manager. the above workaround installer including the old tap (9.21.2) works nicely. |
I made the workaround installer official until I get the signature issue resolved. I submitted the tap-windows6 driver files to the Windows developer dashboard for signing, but I'm not sure how long the process will take. We're probably speaking of at least a week. |
The reason for sticking to cross-signing was to have a driver that is supported by all versions of Windows, wasn't it? If we go this attestation signing route, we'll have to jump through too many hoops (aka HLK/HCK) to get a driver that supports not just Win10 but older desktop and server versions. Any changes to tap-windows will become a major pain going forward. Anyway, the reason cross-signing has failed this time appears to be because the certificate used to sign the new driver was issued in Aug 2016 (not prior to the July 29, 2015 cut-off date). The exception clause for cross-signed cert is not very clear, but seems to imply the signing certificate ("end-entity cert") has to be issued before that date. The old one was issued in 2013. If that is the case we don't have much option but use cross-signing plus attestation to have one version that supports most end users and another cross-signed only for the rest? There are no good options here. |
Same error for me. |
The process for properly signing drivers for Windows 10 is quite convoluted. I will try to get the signing process sorted out by next week. Installers scripts will require changes so a full release is even farther away. |
Uh. The one currently on their site works perfectly fine. |
Tap-windows 9.22.1 does not work on recent Windows 10 that has secure boot on and is a fresh install based on revision 1607 or later. This has everything to do with signatures - Microsoft made signing requirements much more strict and we're setting up the infrastructure to build, sign and test 9.22.1 so that these Windows 10 systems can accept it. |
Yesterday I reinstalled my work laptop using Microsoft Windows 10 Enterprise (10.0.17134 Build 17134) and openvpn-install-2.4.6-I602.exe, which includes TAP-Windows 9.21.2, worked flawlessly. Maybe you have something else on your computer that's interfering? |
OK, this is funny. This afternoon the TAP interface disappeared. In Device Manger the interface was no longer available under Network adapters, however a mysterious "Unknown device" appeared under Other devices, bearing a description of "tap". I uninstalled the unknown device, uninstalled TAP-Windows, and then reinstalled it using http://build.openvpn.net/downloads/releases/tap-windows-9.22.1-I602.exe and lo and behold the device refused to start with the usual error:
Here's the install log:
|
I don't think it's that simple. I tried a couple of things. I uninstalled everything (devices, drivers, programs), rebooted, tried to install http://build.openvpn.net/downloads/releases/tap-windows-9.22.1-I602.exe: driver error. I uninstalled everything, rebooted, installed http://build.openvpn.net/downloads/releases/openvpn-install-2.4.6-I602.exe again (as I did yesterday): everything works and I'm able to connect. In Windows Defender I have everything except Force randomization for images (mandatory ASLR) (since that screws up Git/Cygwin) enabled: |
I was talking about the origin of the problem. Your hypothesis is not holding, at least for me: Windows is loading the driver, the device is working, I'm able to establish a VPN connection. So it Works For Me™. At the moment. The driver signature is either always valid or always invalid, it can't be valid for some people and not for others or work fine for hours/days and then suddenly stop working, unless there's something else at play. Is this caused by specific settings? Security suites? Aliens? I don't know. |
Hi,
On Fri, May 25, 2018 at 07:44:43AM -0700, CHEF-KOCH wrote:
I have some serious doubts if the developers can't even properly sign
the driver how insecure the code is,
Thanks for your trusting words.
last I've seen there wasn't any code audit or review.
Actually, the driver quality is fairly good, which is why we did not have
to bother with the recent changes from Microsoft. Our signing process
worked fine to the early Win10 versions - and we did not *need* to release
new stuff, because no bugs were found (until recently).
This is really shocking and one update in a year or so is not enough to keep up with MS changes.
If there is nothing to change, there is no need to do updates.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
Hi,
On Fri, May 25, 2018 at 08:17:32AM -0700, Albireo wrote:
The driver signature is either always valid or always invalid, it can't be valid for some people and not for others or work fine for hours/days and then suddenly stop working, unless there's something else at play. Is this caused by specific settings? Security suites? Aliens? I don't know.
The signature is valid (as in: the code matches the checksum that the
signature attests). But the windows driver requirements have changed,
and a normal "full blast EV sha256 code signing certificate" is no longer
good enough for Win10/current - the signature is still good, but windows
wants a more strongly trusted certificate.
Which we're working on.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
Hi,
On Sat, Mar 23, 2019 at 04:50:29AM -0700, William Gathoye wrote:
Hello everyone. I think we can close this issue then.
For my Chocolatey package, I had to retest the process from scratch and have been able to establish an OpenVPN connection over the TAP driver with the following configuration:
Which TAP driver version? 9.21.x is expected to work (but old and cannot
be bugfixed), 9.22.x is expected to not work.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
@cron2 That's 9.21.2, actually the one provided built in the OpenVPN 2.4.7 NSIS installer. Btw, guys, you are making this overly complicated by having different version numbers. 9.21.2 is actually 9.0.0.21 when displayed from the Windows Devices Manager. Even if this is not related to this signature issue, I know WireGuard is rewriting a TAP driver for Windows. Maybe this would be time to coordinate efforts or maybe use their reimplementation which is advertised as being faster any way. |
Hi,
On Sat, Mar 23, 2019 at 05:00:46AM -0700, William Gathoye wrote:
@cron2 That's 9.21.2, actually the one provided built in the OpenVPN 2.4.7 NSIS installer.
Btw, guys, you are making this overly complicated by having different version numbers. 9.21.2 is actually 9.0.0.21 when displayed from the Windows Devices Manager.
We're actually trying to get that fixed - so whenever we get the testing/
signing done, the version number will also be in line.
Even if this is not related to this signature issue, I know WireGuard is rewriting a TAP driver for Windows. Maybe this would be time to coordinate efforts or maybe use their reimplementation which is advertised as being faster any way.
Well, the last mail I saw was "it's new, but still slow"...
Plus, it does not have the necessary signatures either :-)
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
Hi guys, |
Hi,
On Tue, Apr 02, 2019 at 06:44:14AM +0000, lomnicky wrote:
is this problem related to signatures only or do you still expect more fixes in tap-windows6 master prior to submitting it to MS? Can you, please, tell me which commit of tap-windows6 is the one that is about to be submitted?
We have a bunch of patches required for WLK test passing. These will
be merged over the next weeks, and then we have the "final" commit for
MS submitting.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
Hi @cron2, I would love to help out with work the you are doing to get WHQL certification.
Anyway, wondering how far along you are and if I could help you out in getting this work done quickly. |
Hi,
On Thu, May 02, 2019 at 02:19:20AM -0700, jamallx wrote:
2) I am trying to get WHQL tests running on Windows 10, I know you are focusing on Windows Server but the tests seem to be the same. The 1 machine tests were straight forward and all are passing. How have you configured your environment for the 2 machine tests? I tried an openvpn connection between the Support and Test, however most of the tests are failing. Have you tried another method to run these tests.
Anyway, wondering how far along you are and if I could help you out in getting this work done quickly.
You need to have "--dev tap" OpenVPN for the 2 machine tests to have
a chance to succeed, but they will still fail because the necessary
code changes are not merged (802.1p priority support etc). @mattock is
working on documenting the test setup, and I should be working on merging
the patches that we have...
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
That is wonderful to hear! Happy to help in anyway I can, so let me know where I can be of assistance, even if it is trying out some of the documentation while it is in the early stages. I was focusing on getting the 2c_Mini6Performance tests passing first. Thanks for the hint using --dev tap will see how that goes. Are you using server-bridge as well? |
@jamallx what timezone are you on? We have a mini-hackathon tomorrow (starts "in the CEST morning") on #openvpn-devel IRC channel on Freenode. I'll be there and will be working on the HLK test setup. I'd love to have "brothers in arms" present there if possible 😄. |
@mattock I usually work on the +5 timezone. Will do my best to join tomorrow (you are probably getting started around my lunch time). At a minimum will get on the IRC channel and start participating: Summary of my setup is: The single machine tests were not too hard to get working. Just had to add some OIDs to make the tests happy. Just started on the 2 machine tests and so far running into lots of failures. Is there any WIP branch I can start helping on? |
Hey @jamallx - I have been working on HLK compliance for tap-windows6 with mattock and cron2 - All tests will pass on my work branch - https://github.com/sgstair/tap-windows6/tree/hlkwork |
I've had good discussions with the wintun developers who were able to make their HLK tests pass already. Quoting the summary of our previous community meeting:
Right now I have Windows Server 2016 HLK controller, one virtualized (EC2) Windows Server 2016 HLK client, OpenVPN server for HLK tests, and one physical Windows Server 2016 instance. I'll make that work first, then extend the setup as needed. |
Hi,
On Thu, May 02, 2019 at 06:27:21PM -0700, Stephen Stair wrote:
Hey @jamallx - I have been working on HLK compliance for tap-windows6 with mattock and cron2 - All tests will pass on my work branch - https://github.com/sgstair/tap-windows6/tree/hlkwork
Some of the tests require a tunnel configuration and private OpenVPN server at the moment (to pass all of the required packets), things should get more clear Friday :) (I am in UTC-8, but will be around for some of the festivities)
To have it documented somewhere
- tap-windows6 has received almost all codes required for the HLK stuff
(the TapDiag bits are missing, which are needed for the priority HLK
tests - working on them now)
- our (Stephen's) original test setup was using an openvpn "--mode server"
server setup, with two clients, all using "--dev tap" mode. We ran into
problems with that because the server will not forward unknown-unicast
frames between clients, so the test failed ("not all packets received").
I did a patch for that, but it might not be necessary at all in the
end - @jamallx came up with a brilliant idea, namely, run OpenVPN in
point-to-point mode. Both sides configured as "--mode p2p" (default),
and either one of them running "--tls-server" and the other one
"--tls-client", or even more barebones, run with "--secret" in true
openvpn peer-to-peer mode. Which dumbs openvpn down to a long
ethernet cable (with crypto), and no sort of internal decision logic
on packet handling - "what comes in via tap is encrypted with the
static key, and sent to the remote address". No state, no handshake,
as barebones as you can get.
Then, run this from the openvpn service, and things should be easy
(but I leave this part of the setup to @mattock)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
I suggest you exclude the computer running an OpenVPN server from the test pool. Otherwise, you risk random test failures when the server computer performs reboot between tests and/or performs reboot test, making your OpenVPN connection to flicker. |
Hi,
On Mon, May 06, 2019 at 07:46:52AM +0000, Simon Rozman wrote:
> 2 Windows 1903 Clients connected to each other using openvpn (one is a server the other as a client)
I suggest you exclude the computer running an OpenVPN server from the test pool. Otherwise, you risk random test failures when the server computer performs reboot between tests and/or performs reboot test, making your OpenVPN connection to flicker.
"do not use an OpenVPN Server at all" - for a two-machine-tests, using
"mode p2p" with "secret" is much more robust against timing issues.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
fwiw 9.23.3.601 is throwing a signature error on windows 10 1903 |
@klepp0906 are you sure you used the "win10" installer? |
Sort of. I actually have torguard vpn installed, which installs the tap9 driver but the ooooold one. So i extracted the exe and used device manager to update the driver. It works fine after disabling driver signature enforcement. Until I restart that is. That leaves my options with A) old driver or B) disabling secure boot and perma disabling driver signature enforcement. |
Hi,
On Mon, May 20, 2019 at 08:16:19AM -0700, klepp0906 wrote:
That leaves my options with A) old driver or B) disabling secure boot and perma disabling driver signature enforcement.
the win10 driver should work just fine, with signatures enabled
(and it does so for lots of other people).
So maybe you just got the wrong package... - could you try just
installing the openvpn-win10.exe to see if you get a working driver
that way? (You do not need to *use* openvpn, obviously :-) )
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
you bet! I'll give it a try and post back. If its working for other people I can only assume i either A) had the wrong package, or B) it requires the entire package to be installed and manually installing just the driver via Device manager isnt adequate. |
@cron2 The driver does install/function properly if installed through the tap-windows.exe. if you attempt to further extract tap-windows.exe and install the driver itself OemVista.inf through device manager - it fails however. Now that I know this, problem solved :) Thanks again! |
Ok. Can we assume this issue is solved now? Are we expecting a new OpenVPN release soon (just to know since I maintain the OpenVPN package on Chocolatey)? |
Hi,
On Wed, May 22, 2019 at 12:49:23PM -0700, William Gathoye wrote:
Ok. Can we assume this issue is solved now? Are we expecting a new OpenVPN release soon (just to know since I maintain the OpenVPN package on Chocolatey)?
We had a new OpenVPN release just recently, with the new tap driver :-)
What we currently have is not perfect - it's two different installers,
one for "pre Win10" and one for "Win10", and neither works on recent
*Server* versions (Server 2016 and up). This is still being worked on.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
@jamallx I'll misuse this thread as I didn't know how else to reach you. I'm about to setup my own physical HLK environment and would like to avoid unnecessary detours. A couple of questions that come to mind:
|
@mattock : Did you get confirmation of successful installation on Win10 machine (where otherwise it was failing) with your workaround build i.e. tap-windows-9.22.1-I602.exe. |
@agrawalamit2005 there is no need for workarounds for Windows 10 desktop. Just use the Windows 10 installers from https://openvpn.net/community-downloads/. The Windows 10 installers have updated, attestation-signed (=Microsoft-signed) tap-windows6 drivers which any Windows 10 desktop should accept. |
I still get error when installing the tap driver. Using Windows 10 64bit v1809 OS build: 17763.379 |
After installing 9.22.1 the adapter in device manager throws the following error.
Microsoft Windows 10 Enterprise 2016 LTSB
10.0.14393 Build 14393
Microsoft Windows 10 Pro
10.0.16299 Build 16299
The text was updated successfully, but these errors were encountered: