OpenVPN authentication: client certificate DN match against user database
-
I've just upgraded the secondary node of a pfSense 2.0 CARP failover firewall to 2.1 (today's snapshot). The primary is still on 2.0 until my problem (see below) is resolved.
The problem is that an incoming OpenVPN connection is now refused on 2.1 which used to work with 2.0 (unchanged config, unchanged client).
This happens with OpenVPN authentication in "Remote Access (SSL/TLS - User Auth)" mode which seem to be related with Blank characters in the client certificate subject.
In my user database (local) I have a user "Martin_Bartosch" (the user manager does not allow blanks in user names, hence the underscore).
My Certificate uses the DN
Subject: DC=de, DC=xxxx, O=xxxxx, CN=Martin BartoschNow, the certificate contains a blank, whereas the user manager uses an underscore in the same place. This definitely works in 2.0 and I saw this as a feature.
With 2.1 however, I cannot authenticate against the OpenVPN server any longer with the same user database.Currently I see two options:
- allow blanks in user names (quite likely not possible)
- do not consider characters disallowed for pfSense user names in equality check of user name against certificate subject.
Any suggestions for a quick fix so I can upgrade my primary node as well to 2.1?
My log contains the following error messages:
Aug 23 13:20:35 exgate1 openvpn[37191]: xxx.xxx.xxx.xxx:9336 [Martin Bartosch] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:9336
Aug 23 13:24:17 exgate1 openvpn: Username does not match certificate common name (Martin_Bartosch != Martin Bartosch), access denied.
Aug 23 13:24:17 exgate1 openvpn[37191]: xxx.xxx.xxx.xxx:25552 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 1 -
Any suggestions for a quick fix so I can upgrade my primary node as well to 2.1?
Sure.
1/ Uncheck "Strict User/CN Matching" in server config.
2/ Do not use spaces in CNs. -
Any suggestions for a quick fix so I can upgrade my primary node as well to 2.1?
1/ Uncheck "Strict User/CN Matching" in server config.
2/ Do not use spaces in CNs.Already did the first.
The second option is not applicable for me due to policy reasons of my internal PKI.
In my opinion the best way to handle this properly would be to support X.509v3 SubjectAlternativeName mappings (see RFC5280, section 4.2.1.6).
The RFC basically states that a certificate's subject should be ignored in favor of a SubjectAlternativeName if it is present in the certificate. If the SAN exists, the relying party should use this value for authorization purposes instead of the subject.The idea then is to add a SubjectAlternativeName (i. e. email address) to the user certificates. Also record an email address in the user directory.
When matching the login user with the certificate, check if the SAN exists. If so, verify that user's email address is listed in the SANs of the certificate presented. -
In my opinion the best way to handle this properly would be to support X.509v3 SubjectAlternativeName mappings (see RFC5280, section 4.2.1.6).
The RFC basically states that a certificate's subject should be ignored in favor of a SubjectAlternativeName if it is present in the certificate. If the SAN exists, the relying party should use this value for authorization purposes instead of the subject.Needs to go to OpenVPN upstream. Not to mention… policy reason. If you have policy "reasons", they'll just not issue any such thing with SubjectAlternativeName either.