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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx