common_name is blank in client-connect script

[csoto]

I have setup a server with

auth-user-pass-verify script
auth-user-pass-optional
username-as-common-name

so I can have clients that can join with just the certificate (normally secured servers and routers) and other clients need to do a doble authentification with certicate and user/password. The auth-user-pass-verify scripts takes care of which clients need to be validated againsts the users/password table. I also want the clients that login with a user to pickup the profile (route, firewall rules, redirections, etc) of that user for which I try to use in the client-connect script with the username-as-common-name. This works fine for clients that do the double validation.

The problem is that when a client joins with just the certificate without a user/password, the server set the common_name variable blank and when the client-connect script gets called I have no idea which profile to load. As the common_name is key to identify the session, I think that it should never be blank. Shouldn't it be that if a user_name is blank then the common_name should remain as it is in the certificate and not attempt to change it?

[csoto]

Checking the source code, it would be a very simple change. Here is the diff:

diff --git a/ssl.c b/ssl.c
index a1268ac..381ab07 100644
--- a/ssl.c
+++ b/ssl.c
@@ -3718,7 +3718,7 @@ key_method_2_read (struct buffer *buf, struct tls_multi *multi, struct tls_sessi

if (man_def_auth != KMDA_UNDEF)

ks->auth_deferred = true;

#endif

• if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME))

+ if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME) && (strlen (up->username)))

set_common_name (session, up->username);

#ifdef ENABLE_DEF_AUTH

msg (D_HANDSHAKE, "TLS: Username/Password? authentication %s for username '%s' %s",

I am pretty sure this is not the way to report the patch but I will continue reading the wiki and submitted properly if there some interest

Carlos

[Eric Crist]

It would be better to suggest this patch via the mailing list. Also, this bug being 2 years old, if this is a bug, it may have been fixed in another code patch. Please re-submit this if it is still an issue.