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. > ----- "Myles Bunbury (Myles)" <[email protected]> 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) > > While that works for this particular case, I'm trying to develop something > where the regex string will be constructed based on an arbitrary certificate > supplied at runtime. > > Questions: > 1) Is it possible to configure httpd to match UTF-8 characters without all > the escaping? It depends on whether that CN attribute is really encoded as an ASN.1 UTF8String. The form quoted above actually suggests that it is a BMPString instead (aka UTF-16BE), which aways uses two octets to encode a character - also for those in the 0-255 range (ASCII, ISO-8859-x). That's the reason why there are quite a few \\x00's in your expression. In theory, you could try inserting literal null bytes into the httpd config file, but I'm not sure if mod_ssl (or the parser for SSLRequire, more specifically) would be able to handle them properly. > 2) If all the "\\x" escaping is necessary, why are there 3 spaces in the > escaped string when they're not present in the certificate? (One space is > after CN=, one after \\x00d, and one after \\xFD.) Because that's how the following characters are encoded in UTF-16: “ U+201C ” U+201D € U+20AC (cf. http://www.unicode.org/charts/PDF/U2000.pdf, 0x20 is SPACE) Kaspar
