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.
Regards, Joe
