On Monday 20 December 2010, Kaspar Brand wrote: > > 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.
The problem is that ssl_var_lookup can be called for an open connection before the request_rec is created. In the current trunk, this does not seem to be done for the SSL_*_DN variables, but it is done for other variables like SSL_CLIENT_S_DN_CN. So the question is: Do we accept that modules which may call ssl_var_lookup for SSL_*_DN without request_rec may get the result in an unexpected format? > 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). OK, makes sense.
