On 20.12.2010 22:28, Stefan Fritsch wrote: > 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?
My answer is yes - I consider it acceptable (if others disagree, please
say so). I can't think of many cases where processing
SSL_{CLIENT,SERVER}_{I,S}_DN *before* having read the request is really
useful, especially not outside mod_ssl.
Looking at what other modules make use of ssl_var_lookup, we actually
find that all of them call it at a time when the request_rec
is indeed available:
mod_rewrite:
result = rewrite_ssl_lookup(r->pool, r->server, r->connection, r,
var + 4);
mod_headers:
const char *val = header_ssl_lookup(r->pool, r->server,
r->connection, r, name);
mod_proxy_ajp:
if ((envvar = ap_proxy_ssl_val(r->pool, r->server, r->connection, r,
AJP13_SSL_CLIENT_CERT_INDICATOR))
For testing purposes, I have created the attached sample cert, which
includes a few, umm, special features - to allow testing the rendering
of the SSL_CLIENT_S_DN_* variables, in particular. It's a PKCS#12 file
with an empty password, so the cert can be imported into a browser
for client authentication test. To get a better picture of what's
included in the DN, "openssl x509 -nameopt sep_multiline,show_type ..."
can be used.
Kaspar
httpd-user-testcert.p12
Description: Binary data
