SSL DN variable unicode handling

[Alex Addy]

We are using the DN of a user's certificate to identify them in the system.
This makes for a better user experience once they have installed their
certificates. But having the backing services have to parse the DN just to
get something readable is annoying at the least. But the way things are
moving we may end up having to do more complicated things with the DN so
the addition of this would be relatively minor.

On Mon, Feb 13, 2017 at 11:01 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Mon, Feb 13, 2017 at 10:19:36AM -0500, Alex Addy wrote:
>
> > While testing the new $ssl_client_s_dn variable (as of 1.11.6) I
> discovered
> > that it doesn't handle unicode characters correctly, Say if I had a user
> > cert with a DN of 'CN=доверенная третья сторона' after going through
> nginx
> > it becomes 'CN=\D0\B4\D0\BE\D0\B2\D0\B5\D1\80\D0\B5\D0\BD\D0\BD\D0\B0\
> D1\8F
> > \D1\82\D1\80\D0\B5\D1\82\D1\8C\D1\8F
> > \D1\81\D1\82\D0\BE\D1\80\D0\BE\D0\BD\D0\B0'.
> > This is not very helpful and unicode support here is the only thing
> > preventing our project from using nginx. We are currently using httpd as
> it
> > handles this case in a more friendly way, but would like to move away
> from
> > it.
> >
> > Is there something I can set to fix this? Is this a bug or is it working
> as
> > intended?
>
> This is intended.
>
> To produce the $ssl_client_s_dn variable nginx uses the
> X509_NAME_print_ex() function with the XN_FLAG_RFC2253 flag.  It
> doesn't try to preserve multibyte characters unescaped (it is
> possible by unsetting the ASN1_STRFLGS_ESC_MSB flag), as it is
> unknown if the variable will be used in an UTF-8-friendly
> environment or not.
>
> Note well that the form with escaped multibyte characters is
> correct as per RFC 4514 (and RFC 2253), as RFC 4514 allows
> escaping of any characters.  Any complaint software can properly
> parse the resulting string to the original DN.
>
> If you need a variable with multibyte characters unescaped for
> some reason, it might be a good idea to elaborate what are you
> trying to do.  May be someone will be able to suggest a better /
> alternative way to do this.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx




-- 
-------------
- Alex Addy -
-------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170213/d87591dc/attachment.html>