What's new

How are common name unique openvpn profiles created?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Weblee2407

Regular Contributor
I followed the instructions for OpenVPN using Easy-RSA generated certificates here:

I copied the generated certificates into the Keys and Certification areas of the VPN server advanced page
certfields.GIF


I could not get any client to connect. After much reading and testing without success, I then clicked the Renew Certification button on the VPN General screen. I then exported the OpenVPN profile and tried it on an iPad, and it successfully connected. I can also connect using Windows and Ubuntu, but when all three are connected, I only see one client on the VPN status tab. There are flashes of a connection of a client named UNDEF, but it is too brief for me to gather any other information. I found information that this has to do with multiple clients using a profile with the same common name in the certificate. In checking the certificates in the GUI, the DH, CA and server are NOT the same as those I generated via easyRsa.

Where are these (GUI) certificates being generated, and how can I use the CA it created to generate common name unique client certificates?

While I can generate unique common name certificates using the easyRsa method, I cannot on the GUI.

Thanks in advance.
 
When you use EasyRSA, *YOU* are responsible for ALL the files. You generate the self-signed CA cert. You generate the server and client certs and keys. You determine the CN (Common Name) on those client certs. You specify the CA, server cert and key, and DH on the server. You specify the CA (same as the server CA), client cert and key on the client. You manage the whole thing from soup to nuts.

As a result, there shouldn't be any need to renew certs since you just created them! The server doesn't even have the necessary CA private key in order to (re)generate them anyway. That private key was created w/ EasyRSA on the PC, which was then used to create the CA, server, and client certs.

In short, once you go outside the router, you can pretty much ignore anything having to do w/ managing these certs and keys. It's all managed by EasyRSA on the PC. You just copy them between the PC and router. About the only thing the router still offers is perhaps the OpenVPN client export file.

One more thing. Be careful when it comes to tutorials about EasyRSA. This utility has gone through numerous revisions over the years (iirc, currently up to v3.x), and unfortunately, w/ each major revision, the changes have usually lead to older tutorials providing outdated information. For example, if you build a script to invoke EasyRSA v2, you'll find it no longer works w/ v3. The author(s) routinely fail to make it backward compatible, which is really annoying. Specifically, v3 now has a single executable called easyrsa that takes command line arguments for configuring these various options rather than individual batch scripts. And v3 has been around quite some time.
 
Last edited:
Based on your response, my next step is to find out how to use the single profile the GUI generates on all the different devices. I read something about "username as common name" but I am using TLS authentication. My guess is I just put a statement for username and password in the profile, but I will try it out and see what happens.
 
Based on your response, my next step is to find out how to use the single profile the GUI generates on all the different devices. I read something about "username as common name" but I am using TLS authentication. My guess is I just put a statement for username and password in the profile, but I will try it out and see what happens.

If you're generating per-client certs and keys w/ EasyRSA, there's no need to use username/password. Users can be disambiguated based on the CN (Common Name) of their respective certs. In fact, to continue using username/password would be equivalanet to requiring username/password for SSH when users were already using public/private keypairs for authentication. Nobody does that because it's just not necessary. The public/private keypair is more than sufficient.

As I said before, the reason the router uses username/password is because it defaults to a single, shared client cert and key for all potential clients. It only does this for the convenience of the router. It's significantly more complicated for the router to manage per-client certs and keys. So it offers a compromised solution, one where everyone shares a single, shared cert and key, *plus* username/password for disambiguating those users, should that prove necessary (e.g., site-to-site).

So you just have to decide whether you want to manage per-client certs and keys, OR, live w/ the default, compromised solution of the router. In many cases, the latter is sufficient. But in some cases, it's the former. Only YOU can make that determination.

What would be a good example for managing all your own files w/ EasyRSA? Suppose you're an admin providing VPN access to employees at work. It would be much safer and far more convenient to give each employee their own cert and key, since once that employee left the company (or perhaps their device is lost or stolen), you can simply revoke that particular cert. But if ALL your users are sharing a single cert, you'd have to revoke that shared cert and deploy a replacement for ALL your users!
 
The public/private keypair is more than sufficient.
As long you also password-protect the certificate. Otherwise, anyone copying your config file would get access.
 
If you're generating per-client certs and keys w/ EasyRSA, there's no need to use username/password. Users can be disambiguated based on the CN (Common Name) of their respective certs. In fact, to continue using username/password would be equivalanet to requiring username/password for SSH when users were already using public/private keypairs for authentication. Nobody does that because it's just not necessary. The public/private keypair is more than sufficient.
This approach is more in line with what the home IT guy had in mind. Thanks, I will work on getting the managed certificate approach working.
 
Well after much reading I was able to establish my CA and issue certificates with device specific common names. Both Windows and Apple devices can connect and pretty good through put.

For anyone else out struggling to get this working here are a couple of pages I found clarifying and helpful...
I didn't have a good grip on static key, channel security and HMAC !

I wasted a lot of time because I was using easy-rsa 3 and it just wouldn’t work; had to use an older rev 2.2.

I did a lot of trial and error and ended up resetting and reconfiguring. Found out I have a pretty good recovery process.

1663474244989.png


Thanks to everyone!
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top