Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#331 closed Bug / Defect (worksforme)

Windows 8 and 'cryptoapicert' does not work.

Reported by: beaukey Owned by: jamesyonan
Priority: major Milestone: release 2.4
Component: Certificates Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: cryptoapicert windows8
Cc: james@…

Description

Issue: Windows 8 and 'cryptoapicert' does not work.

  • A configuration for Windows 7 + 'cryptoapicert' works. Working OVPN configuration file:

dev tun
client

remote {OpenVPN host)
proto tcp-client
port 443

comp-lzo

ca ca.crt
cryptoapicert "THUMB:fc 2c d4 21 4c f3 92 78 52 00 d4 f3 44 79 70 28 69 52 9d 38"

ns-cert-type server

verb 3


  • Using a software based (crt+key file) in Windows 8 works correctly.
  • When I install the certificate (successful) in Windows 8 Certificate Manager (P12 import) OpenVPN fails.

Log file:


Sat Sep 14 13:04:59 2013 us=223068 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Enter Management Password:
Sat Sep 14 13:04:59 2013 us=223068 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sat Sep 14 13:04:59 2013 us=223068 Need hold release from management interface, waiting...
Sat Sep 14 13:04:59 2013 us=566951 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sat Sep 14 13:04:59 2013 us=691960 MANAGEMENT: CMD 'state on'
Sat Sep 14 13:04:59 2013 us=691960 MANAGEMENT: CMD 'log all on'
Sat Sep 14 13:05:00 2013 us=410646 MANAGEMENT: CMD 'hold off'
Sat Sep 14 13:05:00 2013 us=410646 MANAGEMENT: CMD 'hold release'
Sat Sep 14 13:05:01 2013 us=457616 MANAGEMENT: Client disconnected
Sat Sep 14 13:05:01 2013 us=457616 Cannot load certificate "THUMB:‎fc 2c d4 21 4c f3 92 78 52 00 d4 f3 44 79 70 28 69 52 9d 38" from Microsoft Certificate Store: error:C5065064:microsoft cryptoapi:CertFindCertificateInStore:Cannot find object or property.
Sat Sep 14 13:05:01 2013 us=457616 Exiting due to fatal error


Running as User or Administrator makes no difference.
Certificate in User store or Computer store makes no difference.

Change History (5)

comment:1 Changed 11 years ago by Samuli Seppänen

Cc: james@… added
Milestone: release 2.4
Owner: set to jamesyonan
Status: newassigned

comment:2 Changed 10 years ago by Steffan Karger

Are you still experiencing this issue?

I was fiddling with cryptoapicert on Windows 8.1, using OpenVPN 2.3.4. For me everything just worked flawlessly. I used the same syntax you specifiy here (cryptoapicert "THUMB:00 11 22 ...").

Maybe OpenVPN runs as a user that does not have access to the key/cert in the store (i.e. did you run OpenVPN as Administrator?).

Last edited 10 years ago by Steffan Karger (previous) (diff)

comment:3 Changed 10 years ago by beaukey

We re-tested the cryptoapicert functionality again in Windows 8.1 with OpenVPN 2.3.4 and 2.3.6 using the same scenario as noted in the initial bug report. The issue seems to be resolved. We always tested with Administrator rights. Thanks.

Last edited 10 years ago by beaukey (previous) (diff)

comment:4 Changed 10 years ago by Steffan Karger

Resolution: worksforme
Status: assignedclosed

Okay, since it works for both of us, I'll close the ticket. Thanks for reporting back!

comment:5 Changed 9 years ago by Camerond

Not sure if I should reply to this, or open a new case.
I have come across the same issue and think I have identified the cause as due to a bug in the mmc snap-in. My setup works in Windows 7 pro, does not work in 8.1 pro. OpenVPN 2.3.7 64-bit.
When selecting and copying the thumb code from the display window of the mmc snap-in, some invisible binary junk gets copied as well.
In my case it is 3 bytes 0xe2 0x80 0x8e. This happens in both the current user and local system stores, and also applies to the CA that gets placed in the trusted root store.
The junk is not present in preloaded certs.

Whether these bytes remain invisible or not depends on the text editor used and on the assumed encoding. In my case it was Notepad++ in UTF-8 mode and the bytes were totally invisible. To make it more confusing, stepping the cursor through the start of the string looks as if there is only a single invisible character.

A useful workaround could be to pretest the string for invalid chars.

The garbage survives a reboot.

Version 0, edited 9 years ago by Camerond (next)
Note: See TracTickets for help on using tickets.