search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.26k stars 2.92k forks source link

cryptoapicert error -2146893802 #494

Closed odysseus31 closed 4 months ago

odysseus31 commented 5 months ago

Hi, I'm using OpenVPN 2.6.8 via openvpn-gui on a freshly installed Windows 10 machine joined to an AD Domain.

I'm trying to use an auto enrolled (via GPO) machine certificate for client authentication. The certificate and key seem to be ok and usable, as i can successfully use them to authenticate to a radius wlan.

Trying to use it via cryptoapicert directive fails however with error -2146893802 (see below)

So I enabled debug log and even had a look at the source code and as far as i can tell this error originates somewhere in the windows cng api. openvpn does indeed find the correct certificate but is then unable to use it's key.

What could be the cause of this problem?

I have attached config and logs.

Cheers, Mathias openvpn.conf.txt openvpn.log.txt

cron2 commented 5 months ago

pinging @selvanair - any idea if this is a problem we can do anything about on the OpenVPN side? Or how to debug that further?

selvanair commented 5 months ago

As per the logs, OpenVPN fails to acquire the key for the certificate.

We look for certificates in the user store followed by the machine store and use the first instance found. One possibility is that the certificate alone (without the key) appears in the user store as well. In which case we'll pick it up but will fail to get the key. Deleting that entry would fix it if that is the case.

Also ensure the user has read access to the key in the machine store.

selvanair commented 4 months ago

@odysseus31 Did my comment above help sort it out? Can we assume this is resolved now?

odysseus31 commented 4 months ago

I got it working. First i checked if had the certificate in more than one store, which wasn't the case. Then i had the idea of the key being unusable because it's not exportable... but then i read in another issue that this doen't matter. Finally i messed around with the key's access rights and set it to be readable by anyone, which did the trick. I reverted to readable by authenticated users afterwards.

It seems i did not understand the architecture of the gui and how it uses the service to start a connection, as i thought that the openvpn process would run under the SYSTEM account... obviously it doesn't!

Thanks again for your quick replies.

selvanair commented 4 months ago

Glad it worked.

It seems i did not understand the architecture of the gui and how it uses the service to start a connection, as i thought that the openvpn process would run under the SYSTEM account... obviously it doesn't!

The service starts OpenVPN with same privileges of its client (the GUI user in this case) to avoid giving the process escalated rights. OpenVPN then delegates tasks requiring privileges to the service. But accessing the ceritifcate key is not one of those tasks.

If you prefer to keep the key not accessible to users you will have to launch OpenVPN process at boot using a different service called the "OpenVPNService" (this will start it as SYSTEM) and then let users control it from the GUI as a "persistent connection". This will also allow interactive "Connect Before Logon" using PLAP from the logon screen.

That said, I think running OpenVPN with least privileges via the GUI + the interactive service is a much safer approach even if that means private key should be user readable (need not be exportable).