Add missing client certificate field variables

[Neil Craig]

Hi

We make pretty extensive use of client cert auth and it'd be massively helpful if NGINX were to expose all the issuer and subject elements as we sometimes use this as a fine-grained logic filter. Our A/V team wants to use NGINX to replace their existing Apache HTTPD layer and this is a barrier to that right at the moment

NGINX currently exposes the issuer and the subject DN but it'd be great to also expose the rest for issuer and also for subject:

C - Country
L - Location
O - Organisation
OU - Organisational Unit

I would imagine (perhaps naively) that the majority of the logic will exist already to do this so I would hope it's not too much work.

If this is of interest but too much work, I can either try dusting off my C skills (i which case i'd perhaps ask for a quick pointer/link to relevant docs) or i might be able to persuade someone here at work to do the dev.

Cheers

[Maxim Dounin]

C, L, O, and OU - are included in DN, as they are compontents of DN. E.g., DN for CAcert's root certificate is:

/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org

You can see O, OU and so on here. That is, fine-grained logic using particular fields can be done using DN and additional string checking, e.g., using ​map. Assuming your issuance process filters out '/', something like this should work to find out OU:

map $ssl_client_s_dn $organization {
    ~/O=(?<tmp>[^./]+)/ $tmp;
}

[Neil Craig]

Thanks @mdounin, that's good to know - I made a wrong assumption.

It seems to me (maybe you'd disagree?) that it'd be helpful to expose the DN components directly as individual variables. Any mileage in that? it'd remove a barrier to entry via reduction in boilerplate.

[Maxim Dounin]

These individual components are almost never used AFAIK, and introducing them as individual variables doesn't looks like a good idea to me. I may be wrong though, and that's why I'm leaving this ticket open for now to see if there is a demand for this.

[bevand10@…]

Neil - I concur with the helpful approach of adding explicit exposure of fields present in Client certs, rather than having to burden users with map declarations etc.

I have submitted a patch to pull out the following data elements. Please comment if you support the idea. We run Apache currently and have a specific need to get at the MS UPN (i.e. the domain account name (SAMAccountName) that's buried inside a Microsoft corporate AD centric client cert). Nginx does not expose that data right now.

The SSL vars I proposed (c/w source code patch ​https://forum.nginx.org/read.php?29,272522) are:

• ssl_client_s_cn (the CN value found in the S_DN field)
• ssl_client_email (the emailAddress value found in the S_DN field)
• ssl_client_ms_upn (the Microsoft UserPrincipalName value, buried inside the Subject Alternative Name field).

While the 1st and 2nd could be viewed as "convenience" vars, the 3rd is significantly different.

Support for extracting and using the UPN value was added to Apache mid 2015, initiated by a suggestion from Redhat (​http://apache-http-server.18135.x6.nabble.com/Using-UPN-from-subjectAltName-with-SSLUserName-td5022196.html). My patch introduces the same ability to Nginx.

OpenSSL had the NID_ms_upn OID added back in 2002 so accessing this value is, in my opinion, is well overdue. ​http://marc.info/?l=openssl-cvs&m=103735951828612&w=2

I've received initial push-back saying that the above are not useful in a corporate environment.

I disagree, which is partly why I invested time to patch Nginx for my corporate environment (where we're transitioning from an Apache NTLM based auth environment which set REMOTE_USER to the microsoft desktop username/AD identity of the user), to Nginx and user certs (20k+ users) setup, where the UPN (aka AD identity) is generally the auth "primary key" in a wide range of systems and is extensively used in LDAP/AD lookup integrations etc.

My proposal allows for proxy configs such as "fastcgi_param REMOTE_USER $ssl_client_ms_upn" and "proxy_set_header REMOTE_USER $ssl_client_ms_upn", as well as mapping the other fields shown above (CN & emailAddress).

Thoughts on a post-card please.