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
