httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anatoli Tubman <anato...@checkpoint.com>
Subject Re: mod_ssl standard environment variables
Date Mon, 24 Sep 2007 12:10:15 GMT
On Monday 24 September 2007, Ruediger Pluem wrote:
> On 09/24/2007 11:12 AM, Anatoli Tubman wrote:
> > On Monday 24 September 2007, Ruediger Pluem wrote:
> >> On 09/24/2007 10:08 AM, Anatoli Tubman wrote:
> >>> Hi,
> >>>
> >>> Somewhere between 2.0 and 2.2 mod_ssl has changed its API radically,
> >>> or rather, eliminated it. I used to access the client certificate via
> >>> the API as an X_509 data type and passed it to my own authentication
>
> Ok. This was caused by r102803
> (http://svn.apache.org/viewvc?view=rev&revision=102803).
>
> >> Which API call did you use in 2.0? Can you give an example?
> >
> > I'm looking at mod_ssl.h as exported by Apache.
> >
> > In 2.0.59 there is a macro myConnConfig() that returns SSLConnRec*. One
> > of the fields of SSLConnRec is X509 *client_cert. There's a lot of other
> > stuff there (the file is 20 kilobytes long) but I'm using just the client
> > cert.
> >
> > In 2.2.0 everything is gone (th file is just over 2K now). Instead, six
> > optional functions are exported, of which I'm supposed to use
> > ssl_var_lookup(). Or I can just getenv() corresponding variables, the
> > result is the same.
>
> I am currently not quite sure whats the best way to solve your problem. I
> guess we either need to fix ssl_var_lookup or we need to have another
> optional function that gives you the data that you need.
>
> Regards
>
> RĂ¼diger

I think the right way to do things is to replace the usage of 
X509_NAME_oneline() with X509_NAME_print_ex():

BIO* bio = BIO_new(BIO_s_mem());
rc = X509_NAME_print_ex (bio, name, 0, flags);
/* extract the characters from BIO here */

The flags should probably be ASN1_STRFLGS_RFC2253. This escapes non-ASCII
characters with \xHH and otherwise leaves the output in UTF-8. ANDing this
with ~ASN1_STRFLGS_ESC_MSB will give pure UTF-8.

Fixing ssl_var_lookup() this way is theoretically the right thing, but it
might break other people's servers that rely on the old incorrect behaviour.
So there could be two practical solutions: either make another optional 
function that does the right thing (it could accept the flags as an 
additional parameter), or provide a configuration option that switches 
between old and new behaviour (and hardcode the flags to be 
ASN1_STRFLGS_RFC2253).

Regards
-- 
Anatoli Tubman

Mime
View raw message