OpenVPN Support Forum

I have a couple of issue I need to address / figure out before we can complete our migration away from our previous vpn product to OpenVPN Connect.

First has to do with client certificates. Our authentication scheme is username + password and client certificate (this satisfies our cyber security policy of using two factors of authentication). I am able to get this up and running on a Windows workstation without much difficulty. The end user simply keys in user name and password, then the server authenticates the client certificate. Easy peasy. However, ideally, I would like to run OpenVPN Connect as a service in the background that automatically connects at boot without any end user intervention or action needed.

I presume that with a username/password factor involved, this wouldn't work, or wouldn't work well at any rate. My questions are 1) is there a way to do this with username + password as one of my factors and 2) is there an alternative to username + password and client certificate? Is there something else I could use besides the username + password factor?

Second issue also relates to client certificates. In an OVPN profile, I can instruct the client software to read certificates from the Windows Certificate Store using the "cryptoapicert" directive. In OpenVPN Connect 3, this searches for a client certificate located in the OpenVPN Certificate Store linked to an end user's Windows account (I presume, but don't know for certain, that if OpenVPN Connect 3 is running as a background service, it would search the local Administrator account's OpenVPN Certificate Store). I would prefer not to go through the steps of deploying certificates to individual Windows accounts if I can avoid it, and we are not even slightly interested in deploying ADCS at this time to do it automatically. Is there a way to get OpenVPN Connect 3 to search the local machine's OpenVPN Certificate Store?

In terms of this last issue, I am finding that OpenVPN Connect 2 is a better product. It searches the local machine's certificate store and it doesn't search a special store called OpenVPN Client Certificates. It simply searches the Personal certificate store for the local machine. This is a much better, much simpler arrangement that should've been maintained with OpenVPN Connect 3. In my opinion of course.

Hello bp811,

OpenVPN Access Server and OpenVPN Cloud both use client and server certificates to verify both the identity of the client and the server. If you want things to run as a system service we recommend that you do not enable username+password verification for the connection profiles that you'll be using for this purpose. The reason is that, yes, you CAN enable username+password authentication on top of client certificates, but doing so means you will have to store these credentials somewhere on the client machine and that is not a great idea.

OpenVPN Connect v3 does have the ability to save username and password and encrypt that information, which is at least better than storing it as a plain-text file, but still, that encryption has to be reversible and so it could be retrieved anyhow. It's better not to leave such credentials on the client side at all and simply set things up so that the connection profile that contains the client certificates is enough to allow the connection when you wish to have the connection run completely unattended. It's simply safer than storing credentials on the client side.

Regarding where certificates are stored and searched for, that has a lot to do with permissions and various platforms' methods of storing and allowing access to certificates. It's simply better to have an area dedicated to the app to store and retrieve certificates. I recommend that you do not deploy certificates yourself but that you simply import the connection profile generated by OpenVPN Access Server or OpenVPN Cloud into the app. It contains the necessary client certificates. If you really want to you can split the private key out of that and import it into the certificate store in the area reserved for this for the app and have it verified through there.

Kind regards,
Johan

Storing the client certificate's private key in plain text in the VPN profile is seriously insecure, and is just as large of a security flaw as saving username + password in a file.

This seems like a major security flaw with the client software. At least with the Windows Certificate Store the private key information is stored encrypted, but with an inline, plain text profile, you don't even get that. And this goes to part of my question about using the cryptoapicert directive. This does not work when running OpenVPN Connect v3 as a background service. I have never gotten the client software to read a user certificate from the Windows certificate store when running as a service (when running with the GUI as a user, it does work). Running as a service with certificates has ONLY ever worked when I had the client certificate embedded inline in the configuration file, which has the security flaw of storing the client certificate's private key in plain text.

This type of setup actually worked better in OpenVPN Connect v2, which could read from the Local Machine's personal certificate store, which greatly mitigated these issues of moving private keys around in plain text. I would be happy to use Connect v2 but support is ending soon, so that's a no go.

@bp18
the next level of security - is to store user certificates in windows certificate store as non-exportable
in that case OpenVPN Connect cannot access this certificate at all
we use Community version