Extracting SSL_CLIENT_S_DN_UID does not work

HI!

(Re-sent since my message through gmane didn't come through.)

Maybe I'm overlooking the obvious but it seems that env var
SSL_CLIENT_S_DN_UID is not set when using a client cert for authentication.

The following env vars displayed in my SSI HTML text are relevant here
(obfuscated to protect privacy):

SSL_CLIENT_S_DN: /O=Company Name/OU=Authc/UID=userid/CN=Full name
SSL_CLIENT_S_DN_UID: (none)

Is it caused by UID not being the leaf RDN?

Ciao, Michael.

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

On Mon, May 19, 2008 at 10:13:45AM +0200, Michael Ströder wrote:
> HI!
>
> (Re-sent since my message through gmane didn't come through.)
>
> Maybe I'm overlooking the obvious but it seems that env var
> SSL_CLIENT_S_DN_UID is not set when using a client cert for authenticat=
ion.
>
> The following env vars displayed in my SSI HTML text are relevant here
> (obfuscated to protect privacy):
>
> SSL_CLIENT_S_DN: /O=3DCompany Name/OU=3DAuthc/UID=3Duserid/CN=3DFull na=
me
> SSL_CLIENT_S_DN_UID: (none)
>
> Is it caused by UID not being the leaf RDN?

That shouldn't make any difference. What versions of OpenSSL and=20
httpd/mod_ssl are you using? The "UID" DN tag is ambiguous and probably=20
maps to something other than what your subject DN uses.

In the current 2.x mod_ssl sources, UID maps to:

#ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
{ "UID", NID_x500UniqueIdentifier },
#else /* old name, OpenSSL < 0.9.7 */
{ "UID", NID_uniqueIdentifier },
#endif

joe
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

Joe,

many thanks for your response.

Joe Orton wrote:
> On Mon, May 19, 2008 at 10:13:45AM +0200, Michael Ströder wrote:
>>
>> Maybe I'm overlooking the obvious but it seems that env var
>> SSL_CLIENT_S_DN_UID is not set when using a client cert for authentica=
tion.
>>
>> The following env vars displayed in my SSI HTML text are relevant here
>> (obfuscated to protect privacy):
>>
>> SSL_CLIENT_S_DN: /O=3DCompany Name/OU=3DAuthc/UID=3Duserid/CN=3DFull n=
ame
>> SSL_CLIENT_S_DN_UID: (none)
>>
>> Is it caused by UID not being the leaf RDN?
>=20
> That shouldn't make any difference.

Ok, fine.

> What versions of OpenSSL and httpd/mod_ssl are you using?

Actually pre-built RPMs shipped with openSUSE 10.3:

# rpm -q openssl apache2
openssl-0.9.8e-45.5
apache2-2.2.4-70.4

Not sure whether these RPMs are based on sources patched by openSUSE.

> The "UID" DN tag is ambiguous and probably=20
> maps to something other than what your subject DN uses.
>=20
> In the current 2.x mod_ssl sources, UID maps to:
>=20
> #ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
> { "UID", NID_x500UniqueIdentifier },
> #else /* old name, OpenSSL < 0.9.7 */
> { "UID", NID_uniqueIdentifier },
> #endif

Hmm, the user ID is already stored by mod_ssl with attribute name "UID"=20
in env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the=20
attribute type seems to be interpreted as UID is it safe to assume that=20
the cert contains the right OID?

If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anyway.=
...

Ciao, Michael.
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

On Fri, May 23, 2008 at 04:46:48PM +0200, Michael Ströder wrote:
>> In the current 2.x mod_ssl sources, UID maps to:
>>
>> #ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
>> { "UID", NID_x500UniqueIdentifier },
>> #else /* old name, OpenSSL < 0.9.7 */
>> { "UID", NID_uniqueIdentifier },
>> #endif
>
> Hmm, the user ID is already stored by mod_ssl with attribute name "UID"=
in=20
> env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the=20
> attribute type seems to be interpreted as UID is it safe to assume that=
the=20
> cert contains the right OID?

No, unfortunately there is disparity between mod_ssl and OpenSSL here. =20
(I don't know why; I think historically the short name mappings were not=20
unique in OpenSSL possibly, something like that)

OpenSSL uses "UID" for NID_userId (OID mapping an exercise for the=20
reader, see obj_mac.h in OpenSSL ;). So in fact that's the tag used for=20
that RDN.

> If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anywa=
y...

It does indeed map to that OID... wrong in what sense?

joe
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

Joe Orton wrote:
> On Fri, May 23, 2008 at 04:46:48PM +0200, Michael Ströder wrote:
>> Hmm, the user ID is already stored by mod_ssl with attribute name "UID=
" in=20
>> env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the=20
>> attribute type seems to be interpreted as UID is it safe to assume tha=
t the=20
>> cert contains the right OID?
>=20
> No, unfortunately there is disparity between mod_ssl and OpenSSL here. =
=20
> (I don't know why; I think historically the short name mappings were no=
t=20
> unique in OpenSSL possibly, something like that)

Hmmpf! So the string representation of SSL_CLIENT_S_DN is completely=20
generated by OpenSSL whereas the single attribute types are generated by=20
mod_ssl by looking at the cert's OID?

>> If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anyw=
ay...
>=20
> It does indeed map to that OID... wrong in what sense?

Because the syntax assigned to attribute type 'x500UniqueIdentifier'=20
(OID 2.5.4.45) is 'Bit String' (OID 1.3.6.1.4.1.1466.115.121.1.6) which=20
cannot be used to store a user ID with characters like 'ABCDEF'.

http://www.alvestrand.no/objectid/2.5.4.45.html

Ciao, Michael.
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

Joe Orton wrote:
> On Fri, May 23, 2008 at 04:46:48PM +0200, Michael Ströder wrote:
>>> In the current 2.x mod_ssl sources, UID maps to:
>>>
>>> #ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
>>> { "UID", NID_x500UniqueIdentifier },
>>> #else /* old name, OpenSSL < 0.9.7 */
>>> { "UID", NID_uniqueIdentifier },
>>> #endif
>> Hmm, the user ID is already stored by mod_ssl with attribute name "UID=
" in=20
>> env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the=20
>> attribute type seems to be interpreted as UID is it safe to assume tha=
t the=20
>> cert contains the right OID?
>=20
> No, unfortunately there is disparity between mod_ssl and OpenSSL here. =
=20
> (I don't know why; I think historically the short name mappings were no=
t=20
> unique in OpenSSL possibly, something like that)
>=20
> OpenSSL uses "UID" for NID_userId (OID mapping an exercise for the=20
> reader, see obj_mac.h in OpenSSL ;). So in fact that's the tag used fo=
r=20
> that RDN.

Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute type=20
'uid' specified for pilotPerson). That seems right to me since it's=20
compliant with RFC 4514 which contains a table of short and long=20
attribute type names and their OIDs (end of chapter 3).

But now I don't understand the #ifdef-statement mentioned above. From my=20
understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST=20
reference NID_userId. To me that looks clearly like a bug in mod_ssl.

Ciao, Michael.

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote:
> Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute typ=
e=20
> 'uid' specified for pilotPerson). That seems right to me since it's=20
> compliant with RFC 4514 which contains a table of short and long attrib=
ute=20
> type names and their OIDs (end of chapter 3).
>
> But now I don't understand the #ifdef-statement mentioned above. From m=
y=20
> understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST=20
> reference NID_userId. To me that looks clearly like a bug in mod_ssl.

Changing it would break backwards-compat which is why the #ifdef is=20
there (so that the _UID variable refers to the same OID regardless of=20
what OpenSSL version si use).

But I don't disagree that it was wrong in the first place. I vaguely=20
recall discussing this somewhere before and deciding we needed an extra=20
_UserID-like variable so people can get the (commoner) pilotPerson-type=20
uid attribute out of the DN too.

joe
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

Joe Orton wrote:
> On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote:
>> Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute ty=
pe=20
>> 'uid' specified for pilotPerson). That seems right to me since it's=20
>> compliant with RFC 4514 which contains a table of short and long attri=
bute=20
>> type names and their OIDs (end of chapter 3).
>>
>> But now I don't understand the #ifdef-statement mentioned above. From =
my=20
>> understanding it MUST NOT reference NID_x500UniqueIdentifier. It MUST=20
>> reference NID_userId. To me that looks clearly like a bug in mod_ssl.
>=20
> Changing it would break backwards-compat which is why the #ifdef is=20
> there (so that the _UID variable refers to the same OID regardless of=20
> what OpenSSL version si use).

1. I seriously doubt that there are any certs out there which use=20
x500UniqueIdentifier in the subject-DN. If yes, then these certs are=20
also seriously broken.

2. It's simply broken that attribute type UID in mod_ssl differs from=20
OpenSSL here.

Ciao, Michael.
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

Michael Ströder wrote:
> Joe Orton wrote:
>> On Fri, May 23, 2008 at 05:23:34PM +0200, Michael Ströder wrote:
>>> Ok, then the OID in my cert is 0.9.2342.19200300.100.1.1 (attribute=20
>>> type 'uid' specified for pilotPerson). That seems right to me since=20
>>> it's compliant with RFC 4514 which contains a table of short and long=
=20
>>> attribute type names and their OIDs (end of chapter 3).
>>>
>>> But now I don't understand the #ifdef-statement mentioned above. From=
=20
>>> my understanding it MUST NOT reference NID_x500UniqueIdentifier. It=20
>>> MUST reference NID_userId. To me that looks clearly like a bug in=20
>>> mod_ssl.
>>
>> Changing it would break backwards-compat which is why the #ifdef is=20
>> there (so that the _UID variable refers to the same OID regardless of=20
>> what OpenSSL version si use).

To come around this: How about letting the deployer specify the OIDs in=20
httpd.conf? Backwards-compability could be achieved with this.

Ciao, Michael.
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Extracting SSL_CLIENT_S_DN_UID does not work

--NextPart_Webmail_9m3u9jl4l_29909_1211894649_0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

DONT SEND ME THIS CRAP THANK'S=20
-------------- Original message from Michael Ströder er.com>: --------------=20


> Joe,=20
>=20
> many thanks for your response.=20
>=20
> Joe Orton wrote:=20
> > On Mon, May 19, 2008 at 10:13:45AM +0200, Michael Ströder wrote:=
=20
> >>=20
> >> Maybe I'm overlooking the obvious but it seems that env var=20
> >> SSL_CLIENT_S_DN_UID is not set when using a client cert for authenti=
cation.=20
> >>=20
> >> The following env vars displayed in my SSI HTML text are relevant he=
re=20
> >> (obfuscated to protect privacy):=20
> >>=20
> >> SSL_CLIENT_S_DN: /O=3DCompany Name/OU=3DAuthc/UID=3Duserid/CN=3DFull=
name=20
> >> SSL_CLIENT_S_DN_UID: (none)=20
> >>=20
> >> Is it caused by UID not being the leaf RDN?=20
> >=20
> > That shouldn't make any difference.=20
>=20
> Ok, fine.=20
>=20
> > What versions of OpenSSL and httpd/mod_ssl are you using?=20
>=20
> Actually pre-built RPMs shipped with openSUSE 10.3:=20
>=20
> # rpm -q openssl apache2=20
> openssl-0.9.8e-45.5=20
> apache2-2.2.4-70.4=20
>=20
> Not sure whether these RPMs are based on sources patched by openSUSE.=20
>=20
> > The "UID" DN tag is ambiguous and probably=20
> > maps to something other than what your subject DN uses.=20
> >=20
> > In the current 2.x mod_ssl sources, UID maps to:=20
> >=20
> > #ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */=20
> > { "UID", NID_x500UniqueIdentifier },=20
> > #else /* old name, OpenSSL < 0.9.7 */=20
> > { "UID", NID_uniqueIdentifier },=20
> > #endif=20
>=20
> Hmm, the user ID is already stored by mod_ssl with attribute name "UID"=
=20
> in env var SSL_CLIENT_S_DN. Given that it's OpenSSL 0.9.8 and that the=20
> attribute type seems to be interpreted as UID is it safe to assume that=
=20
> the cert contains the right OID?=20
>=20
> If NID_x500UniqueIdentifier maps to OID 2.5.4.45 it's plain wrong anywa=
y...=20
>=20
> Ciao, Michael.=20
> ____________________________________________________________ __________=20
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org=20
> User Support Mailing List modssl-users@modssl.org=20
> Automated List Manager majordomo@modssl.org=20
--NextPart_Webmail_9m3u9jl4l_29909_1211894649_0
Content-Type: multipart/related; boundary="NextPart_Webmail_9m3u9jl4l_29909_1211894649_1"


--NextPart_Webmail_9m3u9jl4l_29909_1211894649_1
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable