On 20.11.2010 20:24, Stefan Fritsch wrote:
> On Fri, 19 Nov 2010, Joe Orton wrote:
>> We could support this better by having a new set of exports:
>>
>> SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
>>
>> (or something similarly named)
>>
>> which works the same as _DN_ but exports the attributes as a UTF-8 byte
>> seequence regardless of the underlying ASN.1 type; this would be a
>> relatively simple hack.
>
> Or have a (per vhost) directive that enables conversion for all
> SSL_*_S_DN_* and SSL_*_S_DN to UTF8. IMHO, this could even be enabled by
> default in 2.4.
I prefer the latter approach, yes (there's already an awful lot of SSL_*
something variables).
Given the fact that mod_ssl's current behavior with non-ASCII characters
(i.e., outside the 0-127 range) is mostly undefined and/or sometimes
even erroneous (a BMPString in the subject or issuer DN will end up as
an empty SSL_*_*_DN_* variable, due to the initial null byte), I would
suggest the following solution:
- for all SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, use UTF-8 by default
(i.e., adapt ssl_engine_vars.c:ssl_var_lookup_ssl_cert_dn() to convert
TeletexString, UniversalString and BMPString types to UTF8String)
- for SSL_{CLIENT,SERVER}_{I,S}_DN, don't use X509_NAME_oneline()
any more and switch to X509_NAME_print_ex() instead. What flags
should be used is probably debatable - I would recommend to go with
XN_FLAG_RFC2253 (note that using XN_FLAG_ONELINE with
X509_NAME_print_ex doesn't produce the same string as
X509_NAME_oneline, so this will break backward compatibility
in any case)
- add another parameter to the SSLOptions directive which allows
re-enabling the "old" string rendering for
SSL_{CLIENT,SERVER}_{I,S}_DN (so the new default would be to rely
on X509_NAME_print_ex - even for 2.2 -, but people could restore the
current behavior through this option)
Kaspar
