<div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 11:01 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Mon, Feb 13, 2017 at 10:19:36AM -0500, Alex Addy wrote:<br>
<br>
> While testing the new $ssl_client_s_dn variable (as of 1.11.6) I discovered<br>
> that it doesn't handle unicode characters correctly, Say if I had a user<br>
> cert with a DN of 'CN=доверенная третья сторона' after going through nginx<br>
> it becomes 'CN=\D0\B4\D0\BE\D0\B2\D0\B5\<wbr>D1\80\D0\B5\D0\BD\D0\BD\D0\B0\<wbr>D1\8F<br>
> \D1\82\D1\80\D0\B5\D1\82\D1\<wbr>8C\D1\8F<br>
> \D1\81\D1\82\D0\BE\D1\80\D0\<wbr>BE\D0\BD\D0\B0'.<br>
> This is not very helpful and unicode support here is the only thing<br>
> preventing our project from using nginx. We are currently using httpd as it<br>
> handles this case in a more friendly way, but would like to move away from<br>
> it.<br>
><br>
> Is there something I can set to fix this? Is this a bug or is it working as<br>
> intended?<br>
<br>
</span>This is intended.<br>
<br>
To produce the $ssl_client_s_dn variable nginx uses the<br>
X509_NAME_print_ex() function with the XN_FLAG_RFC2253 flag.  It<br>
doesn't try to preserve multibyte characters unescaped (it is<br>
possible by unsetting the ASN1_STRFLGS_ESC_MSB flag), as it is<br>
unknown if the variable will be used in an UTF-8-friendly<br>
environment or not.<br>
<br>
Note well that the form with escaped multibyte characters is<br>
correct as per RFC 4514 (and RFC 2253), as RFC 4514 allows<br>
escaping of any characters.  Any complaint software can properly<br>
parse the resulting string to the original DN.<br>
<br>
If you need a variable with multibyte characters unescaped for<br>
some reason, it might be a good idea to elaborate what are you<br>
trying to do.  May be someone will be able to suggest a better /<br>
alternative way to do this.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a></font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="monospace, monospace">-------------</font><div><font face="monospace, monospace">- Alex Addy -</font></div><div><font face="monospace, monospace">-------------</font></div></div></div>
</div>