search

OpenVPN / tap-windows6

Windows TAP driver (NDIS 6)
Other
796 stars 237 forks source link

Support for loading code signing certificate from a file #10

Closed jait closed 8 years ago

jait commented 9 years ago

When supplying --certfile=FILE and optionally --certpw=PW, the code signing certificate is loaded from the given file instead of "MY" Store.

mattock commented 8 years ago

Hi, and sorry for this horrible delay.

If I'm not mistaken, Microsoft is forcing everyone to use the "Windows Hardware Developer Center Dashboard" to sign their kernel-mode drivers. I believe this affects tap-windows6 also and thus we can kiss goodbye to automated driver signing, including what is already in the main tap-windows6 repo, as well as your pull request. Any thoughts on this?

Here are a few links I dug up earlier:

https://msdn.microsoft.com/library/windows/hardware/hh801887 https://msdn.microsoft.com/en-us/windows/hardware/hh833792

mattock commented 8 years ago

Responding to my own comment after fighting with Authenticode signatures for way too long. So, it seems that having two sets of Authenticode signatures is in practice necessary. What seems to work a (non-EV) SHA1 signature coupled with secondary EV SHA2 signature. Both need to have matching (=correct) timestamps and cross-certificates, so that the certificate path is intact.

What this means is that this PR actually makes sense, especially if the Windows certificate store contains several certificates of the same (or highly similar) Subject name. For example, if there are three or more code-signing certificates in the certificate store, all issued to the same entity, SignTool.exe will not be able to select the correct certificate in any reasonable fashion, unless the certificate is loaded from a PFX file.

I'll have a look at merging this pull request after I have my own (possibly conflicting) changes to buildtap.py merged. I too would actually prefer loading the certificate from a pfx file, as the certificate store approach gets pretty messy pretty easily.

mattock commented 8 years ago

Interestingly I get merge conflicts when trying to apply these patches to my tap-windows6 repo. I'll try to get the problem fixed and this PR tested tomorrow or on Wednesday.

mattock commented 8 years ago

It seems that "git merge" does more magic than "git am", because that worked fine. Anyways, I can confirm that this patch does not create any obvious regressions, and that it works as intended. Merging.