On 19.12.2010 01:58, Stefan Fritsch wrote: > [email protected],CN=ca,OU=httpd-test,O=ASF,L=San > Francisco,ST=California,C=US > > Is this what we want? We could use XN_FLAG_DN_REV to keep the old > order. I haven't tried UTF8 characters, yet.
Thanks, Stefan, for working on this. My idea with using XN_FLAG_RFC2253 was that this is the only kind of standardized X.509 DN string rendering - so I would not add XN_FLAG_DN_REV to the mix, as RFC 2253 (section 2.1) defines the order shown above. > Instead of an SSLOption (which would require a request_rec to lookup), > I have implemented a per-vhost option for restoring compatibility. Could we pass the request_rec from ssl_var_lookup() to ssl_var_lookup_ssl(), and from there on to ssl_var_lookup_ssl_cert() etc.? SSLOptions seems like the best place to me for such an option, it's where I would expect it to find as an httpd user. I would name the option LegacyDNStringFormat (instead of "...VarFormat"). > Can > we reject such certificates somehow? Should we close the connection if > we see such a thing in ssl_var_lookup_ssl_cert? Or should we try to > escape the 0-byte in the variable? The latter. I suggest using ASN1_STRING_print_ex() with ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as \0). Kaspar
