Please support certificates where a CN attribute is not part of the subject DN

[András Korn]

Hi,

with LDAP deployments becoming more and more commonplace, private PKIs can be expected to try to create a mapping between the LDAP DNs of users and the DNs in their certificates.

A typical LDAP DN at a Unix site looks like this:

uid=username,ou=People,dc=somedomain,dc=tld

It's entirely possible to issue a certificate to this DN as a subject. Alas, using such certificates with OpenVPN is currently impossible; an attempt to do so yields:

VERIFY ERROR: could not extract Common Name from X509 subject string ('/DC=tld/DC=somedomain/OU=People/UID=someuser') -- note that the Common Name length is limited to 64 characters
TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

IIUC, the only point in parsing out the CN is to have a hopefully unique "friendly name" for the client. The --username-as-common-name option looks like a promising workaround, but unfortunately the failure to find a CN in the subject string still causes the connection to fail even if a remote username is supplied and username-as-common-name is enabled.

Please implement one or more of the following:

1. If username-as-common-name is specified, use the remote username as the CN right away and don't even try to parse the CN out of the subject string.

2. Allow the administrator to specify a different attribute instead of CN to look for in the subject string (e.g. uid). This would not be ideal because while people would have uids, devices would still have CNs (so OpenVPN servers may have to deal with differently constructed DNs).

3. Allow the administrator to specify a list of attributes to look for in the subject string to use as CN.

4. Add an option to use the entire DN instead of only part of it to "name" the client.

5. Allow an external script or plugin to set OpenVPN's idea of the CN based on the client certificate (or just the subject string) and/or the username.

6. Require the username (in username+password authentication) to be either the uid/cn from the certificate subject, or the entire DN. This would strengthen double authentication in that it wouldn't be sufficient to know a username/password pair and obtain a valid certificate; it'd be necessary for the client to know the current password of the exact user whose certificate it is using to connect.

Thanks

Andras

[JJK]

this will be fixed in openvpn 2.2 using the new keyword

x_509_user_name

HTH,

JJK

[András Korn]

I think that while the --x509-username-field option is a step in the right direction, it's not quite what I had in mind.

Consider the following two LDAP DNs:

1. cn=some.host.tld,ou=servers,dc=example,dc=com
2. uid=someuser,ou=People,dc=example,dc=com

Even with --x509-username-field, it's impossible to match both, because one of them only has a cn and the other only has a uid. This guts client-config-dir, ccd-exclusive and other options that depend on the extracted CN.

(Also, the manpage isn't quite clear about what --x509-username-field does: does it cause OpenVPN to use the supplied field everywhere where it would normally use the CN, or only as the username for auth-user-pass and its ilk? What (if any) are the interactions with username-as-common-name?)

I think the following suggestions I made in my original wishlist report would still make sense:

3. Allow the administrator to specify a list of attributes to look for in the subject string to use as CN.

4. Add an option to use the entire DN instead of only part of it to "name" the client.

5. Allow an external script or plugin to set OpenVPN's idea of the CN based on the client certificate (or just the subject string) and/or the username.

6. (Somewhat unrelated:) require the username (in username+password authentication) to be either the uid/cn from the certificate subject, or the entire DN. This would strengthen double authentication in that it wouldn't be sufficient to know a username/password pair and obtain a valid certificate; it'd be necessary for the client to know the current password of the exact user whose certificate it is using to connect.

[Steffan Karger]

I see your problem, and quickly glanced over the relevant code in OpenVPN. Although technically possible, I don't think this use case warrants yet another config option to implement, test and maintain. We have enough complexity already.

Instead, just create two openvpn server instances on different ports/IP's. One for 'users' and one for 'machines'. You'll probably want to separate the network segments anyway. Use the --x509-username-field option on the 'users'-instance to remap the CN. That should solve your problem just fine, and give you nice separation and parallelization as a bonus.

Closing this as 'wontfix'.

(Oh, and apologies for the *very* slow response.)