Common name containing underscore
-
I have older user certificates containing underscores that work well with openvpn.
However, I recently generated new certs containing underscores and they are being truncated (at the underscore) when they appear in the openvpn status widget.
The older certs cn appear in full.
Is there a difference in how pfsense now generates certs? -
Are they correct on Status > OpenVPN?
I don't have any with underscores to check but there haven't been any changes to make the certs more strict, only less strict. We've relaxed quite a lot of former restrictions so I don't think anything would be different about an underscore now.
Check under System > Cert Manager as well and click the and make sure the CN and SAN entry both have the full name that isn't truncated.
-
I've created tons of User Certificates with underscore in pfSense 2.4.3-p1 for OpenVPN without any Problems.
-Rico
-
I can't seem to reproduce this either. I made a couple certs with underscores and connected to OpenVPN and the client shows up fine in the widget and on the OpenVPN status page.
-
I can see the correct CN appear in the OpenVPN System Logs.
The CN appearing in the OpenVPN Widget is truncated at the underscore,
however I have another certificate that matches this CN.In other words I have a CN that is "USER" and another that is "USER_Mobile".
The "USER_Mobile" CN appears in the system log but the "USER" CN appears in the widget.I am also using client specific overrides, which I am now experimenting with turning them on and off.
-
Okay, this is not a pfSense fault.
It is appears to be an error with the Android OpenVPN App I was using.
(OpenVPN Client by colucci-web - the Paid Version)
I have imported the same OVPN profile into "OpenVPN for Android" and the CN appears correctly.
Still seems bizarre, given the pfSense logs contain the correct CN from the "OpenVPN Client" App
I will do some more testing. -
The issue is PARTLY my user error.
I had inadvertently put the username & password for the "USER" OpenVPN client profile into the "USER_Mobile" OpenVPN client profile.
And; I had disabled the Enforce the Strict User CN matching whilst fault finding.BUT:
The CN appearing in the OpenVPN Widget appears to be the USER ID;
& NOT the actual CN.This probably is only pertinent to a" Remote Access SSL/TLS + User Auth" OpenVPN Server.
-
That's expected. We pass a config parameter to OpenVPN that tells it to use the username as the common name.
Either way it will be something other than expected, but taking the username is more likely to be accurate and what the user wants.
-
That works fine, confusing when the labelling is inaccurate though.
Shouldn't the CSO refer to user name rather than CN? -
Not necessarily. We go with what OpenVPN says there.
In a purely SSL/TLS VPN, it's the common name (there is no usename). In purely user auth, it's the username. With both, it's still the username.
It would be far too wordy to label it "Common Name/Username" everywhere.
-
Point taken on the real estate issue.
Seems to me that "User Name" is more accurate than "Common Name", as you pointed out: OpenVPN only reverts to the Common Name when no User Name is present.
Trying not to nitpick but this becomes critical when routing via CSO's.(I also notice that there is a tip about this in the GI section of the CSO)
-
Can't you just generate certificates with the exact Username as CommonName and not use username-as-common-name?
Never a problem with CSO that way. -
Yes Pippin, I think that is best practice - and I do that.
You should also ensure that you Enforce CN / User Matching when using CSO's
Otherwise; a user with a valid cert can circumvent the intended CSO routing / firewalling if he knows another user's name & pwd.
(Or a mindless Sys Admin can get himself confused )
