On Fri, 19 Nov 2010, Joe Orton wrote:
On Fri, Nov 19, 2010 at 07:13:01AM +0100, Kaspar Brand wrote:
On 17.11.2010 15:53, Igor Galić wrote:
it might be appropriate to ping dev@ with this problem
I'm not sure if it's a bug or a feature.
I'd call it a missing feature... the problem is that mod_ssl treats all
values of any DN attribute (subject or issuer) as a sequence of 8-bit
characters.
Worth noting that the handling of SSL_*_S_DN is different to the
handling of the individual attributes, SSL_*_S_DN_* - the _DN string is
rendered as an escaped string whereas the attributes are exported as a
sequence of raw bytes. That is all kind of messy (not to mention
undocumented)...
----- "Myles Bunbury (Myles)" <myles.bunb...@alcatel-lucent.com> wrote:
After some investigation, I discovered that this line does successfully pick up
the certificate:
SSLRequire (%{SSL_CLIENT_S_DN} =~ m#^/.*CN= \\x1C\\x00W\\x00e\\x00i\\x00r\\x00d
\\x1d\\...@\\x00\\xbf\\x063\\x01\\xfd \\xAC\\x00.\\x00c\\x00o\\x00m.*$#i)
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.
