Bug 45107 - Client certificate attribute UID not usable in env var SSL_CLIENT_S_DN_UID since wrong NID/OID assigned
Client certificate attribute UID not usable in env var SSL_CLIENT_S_DN_UID si...
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
All All
: P3 normal with 5 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: 29201 (view as bug list)
Depends on:
  Show dependency tree
Reported: 2008-05-31 04:03 UTC by Michael Ströder
Modified: 2014-02-17 13:58 UTC (History)
5 users (show)

Patch for mod_ssl: Map attribute name "UID" to NID_userId (686 bytes, patch)
2008-05-31 04:03 UTC, Michael Ströder
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ströder 2008-05-31 04:03:49 UTC
Created attachment 22042 [details]
Patch for mod_ssl: Map attribute name "UID" to NID_userId

When connecting with a client certificate which contains attribute UID in its subject-DN the following env vars are set:
SSL_CLIENT_S_DN: /O=Company Name/OU=Authc/UID=userid/CN=Full name

From discussion on modssl-users list I've learned that SSL_CLIENT_S_DN contains the string representation of the subject-DN generated by OpenSSL libs and SSL_CLIENT_S_DN_UID is set by mod_ssl.

Furthermore I've learned that SSL_CLIENT_S_DN_UID is set by mod_ssl based on attribute 'x500UniqueIdentifier' (OID I consider this to be seriously broken because the syntax assigned to attribute type 'x500UniqueIdentifier' (OID is 'Bit String' (OID which cannot be used to store a user ID with characters like 'ABCDEF'.

See also http://www.alvestrand.no/objectid/

Furthermore RFC 4514 contains a table of short and long attribute type names and their OIDs (end of chapter 3). See the relevant excerpt:

String  X.500 AttributeType
      ------  --------------------------------------------
      UID     userId (0.9.2342.19200300.100.1.1)

So please consider the patch attached to be applied to mod_ssl to fix this bug.

Thanks in advance.

Ciao, Michael.
Comment 1 Peter Sylvester 2009-06-12 05:23:12 UTC
OpenSSL has changed the definition of the NIDs in question some time
in the past. Until the definition of NID_Userid, the OID was simply wrong.

in the example, the x_DN is correctly formatted using an openssl function. 

The patch replaces the ifdefs and nids by an unconditional use of NID_userId

In order to maintain the possibility to compile with older versions
(without any consideration about their stability in other areas)
I suggest to use

+ #ifdef NID_userId
+    { "UID",   NID_userId                 }, /* officially see RFC 4514 */
+ #endif

Peter Sylvester
Comment 2 Peter Sylvester 2009-06-23 04:41:51 UTC
The bug is the same as for ticket 29201. 

The proposed solution in 29201 to have a different environment variable
doesn't make much sense.
Comment 3 Joe Orton 2009-06-23 07:02:41 UTC
Yes, I think I was convinced by Martin's argument on the mailing list about this.  I will dupe the other bug against this and commit that fix.  Thanks, guys.
Comment 4 Joe Orton 2009-06-23 07:10:34 UTC
*** Bug 29201 has been marked as a duplicate of this bug. ***
Comment 5 Joe Orton 2009-06-23 07:12:18 UTC
Discussion thread, for reference:


Committed in r787683.
Comment 6 Lampa 2009-08-27 07:48:33 UTC
still no working in 2.2.13 (and 2.2.9) (at least for me)

using OpenSSL 0.9.8k 25 Mar 2009 and mod_ssl/2.2.13 compiled against Server: Apache/2.2.13, Library: OpenSSL/0.9.8k

tried old certs and generated new one and also tried userID, UID

after aplying Peter Sylvester minipatch
#ifdef NID_userId
    { "UID",   NID_userId                 }, /* officially see RFC 4514 */
        #ifdef NID_x500UniqueIdentifier /* new name as of Openssl 0.9.7 */
    { "UID",   NID_x500UniqueIdentifier   },
        #else /* old name, OpenSSL < 0.9.7 */
    { "UID",   NID_uniqueIdentifier       },

start working
Comment 7 Peter Sylvester 2009-08-27 08:37:04 UTC
Can someone provide a non working cert and the values of both
Comment 8 Lampa 2009-08-27 10:05:28 UTC
using CustomLog "%{SSL_PROTOCOL}x \"%{SSL_CIPHER}x\" \"%{SSL_CLIENT_S_DN_CN}x\" \"%{SSL_CLIENT_S_DN_UID}x\" \"%r\" %>s %b %T"

before patch:
TLSv1 "DHE-RSA-AES256-SHA" "/C=CZ/ST=State/L=Location/O=Organization/OU=Test Unit/CN=Test User/emailAddress=test@test.com/UID=d1bff376-3788-404f-ae9c-ffffffffffff" "-" "GET / HTTP/1.1" 403 217 1

after patch:
TLSv1 "DHE-RSA-AES256-SHA" "/C=CZ/ST=State/L=Location/O=Organization/OU=Test Unit/CN=Test User/emailAddress=test@test.com/UID=d1bff376-3788-404f-ae9c-ffffffffffff" "d1bff376-3788-404f-ae9c-ffffffffffff" "GET / HTTP/1.1" 403 217 1

also  SSLRequire %{SSL_CLIENT_S_DN_UID} doesn't work


[ req_distinguished_name ]
uid                             = User ID
uid_min                         = 36
uid_max                         = 36

and cert:

Comment 9 Peter Sylvester 2009-08-27 11:03:32 UTC
As far as I understand your log entry:

SSL_CLIENT_S_DN_UID seems ok in your customlog.

before the patch it is "-" (bad) 
after it is "d1bff376-3788-404f-ae9c-ffffffffffff" (good)
Comment 10 Lampa 2009-08-27 13:51:17 UTC
exactly, before patch modules/ssl/ssl_engine_vars.c contains only:

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

and wasn't possible to log only UID ("-" instead d1bff376-3788-404f-ae9c-ffffffffffff in custom log file; DN containted UID) after patch UID appears in custon log file

#define SN_uniqueIdentifier             "UID"
#define LN_uniqueIdentifier             "uniqueIdentifier"
#define NID_uniqueIdentifier            102
#define OBJ_uniqueIdentifier            OBJ_X509,45L

#define SN_userId               "UID"
#define LN_userId               "userId"
#define NID_userId              458
#define OBJ_userId              OBJ_pilotAttributeType,1L
#define LN_x500UniqueIdentifier         "x500UniqueIdentifier"
#define NID_x500UniqueIdentifier                503
#define OBJ_x500UniqueIdentifier                OBJ_X509,45L

openssl x509 -in test2.crt -noout  -subject -nameopt RFC2253  -nameopt sname
subject= UID=d1bff376-3788-404f-ae9c-ffffffffffff,emailAddress=test@test.com,CN=Test User,OU=Test Unit,O=Organization,L=Location,ST=State,C=CZ

openssl x509 -in test2.crt -noout  -subject -nameopt RFC2253  -nameopt oid
subject= 0.9.2342.19200300.100.1.1=d1bff376-3788-404f-ae9c-ffffffffffff,1.2.840.113549.1.9.1=test@test.com, User, Unit,,,,
Comment 11 Peter Sylvester 2009-08-27 14:51:23 UTC
So, where is the problem?

Don't you like tha UID id the OID 0.9.2342.19200300.100.1.1?

Do you prefer OID 

The routine that shows the full Dn uses UID for the 0.9.2342.19200300.100.1.1
since several years since one cannot have a nice representation of

The patch aligns the SSL_type_x_UID variable to match the UID=
in the full DN in alignment with ldap.  

Or do you want certificates that have OID
Comment 12 Lampa 2009-08-27 21:22:37 UTC
problem is that must patch modules/ssl/ssl_engine_vars.c with

+ #ifdef NID_userId
+    { "UID",   NID_userId                 }, /* officially see RFC 4514 */
+ #endif

to get uid working (in my casse) but this is not possible when you use distro packages (debian testing)
Comment 13 Peter Sylvester 2009-08-28 03:31:41 UTC
The patch should be backported as soon as possible so
that packaged standard versions get it.
Comment 14 Lampa 2009-08-28 21:46:45 UTC
great, i hope that will be in next release (2.2.14)

thank you
Comment 15 Guenter Knauf 2009-09-06 17:45:23 UTC
This issue was fixed in 2.2.x branch with r811812 and will ship with httpd 2.2.14.
Comment 16 Lampa 2010-03-25 11:20:26 UTC
Is possible in 2.2.15 version reverted to (eg discarded http://svn.apache.org/viewvc?view=revision&revision=811812):

#ifdef NID_userId
    { "UID",   NID_x500UniqueIdentifier,   1 },

+ #ifdef NID_userId
+    { "UID",   NID_userId                 }, /* officially see RFC 4514 */
+ #endif

Now is not possible to use SSL_CLIENT_S_DN_UID which refers to openssl NID_userId
Comment 17 ymmt2005 2012-07-10 04:44:10 UTC
Just for information, this broke compatibility between Ubuntu 10.04
(shipped with Apache 2.2.14) and Ubuntu 12.04 (shipped with Apache 2.2.22).
Comment 18 Michael Ströder 2012-07-10 07:03:42 UTC
Frankly I don't understand why this bug has been reopened. Anybody who claims that using the correct mapping { "UID",NID_userId} is a regression should elaborate why that is.

IMO maintaining backward compability between distro packages does not have higher priority over fixing wrong behaviour in upstream source. Especially as comment#17 does not contain any useful information about the problem. (I suspect it's a misconfiguration anyway.)

Note that referencing x500UniqueIdentifier in older Apache versions was never correct. It never worked right at all! Never! It was absolutely wrong. Got it?
Everybody having doubts about this should re-read my initial issue text more closely and comment based on real knowledge about structure of X.509 certs.
Comment 19 ymmt2005 2012-07-10 11:30:39 UTC

I'm sorry.  That is a Ubuntu's backward compatibility problem, not apache's.
I agree with you that using userId is appropriate.
Comment 20 Eric Covener 2012-07-10 11:54:10 UTC
Create a new bugzilla entry if you think there's followup work to do here.
Comment 21 Andy Wang 2013-01-31 17:11:17 UTC
I think comment 16 was overlooked in the ubuntu backward compatibility debate.

It looks like:
 #ifdef NID_userId
-    { "UID",   NID_userId                 },
+    { "UID",   NID_x500UniqueIdentifier,   1 },

reverted the attribute back to x500UniqueIdentifier.   Based on comment 18 I think this submission was a regression.

I'll open a new bug report against that.
Comment 22 Andy Wang 2013-01-31 17:16:15 UTC
I opened bug 54510 to report the regression noted in Comment 16
Comment 23 Kaspar Brand 2013-02-02 07:44:30 UTC
Comment 16 (and comment 21) is correct, it's indeed a regression introduced in 2.2.15, with r910319.

As noted in comment 15, it was originally fixed for 2.2.14 with r811812.

Resetting version info to the previous values from 2009. For the fix, see bug 54510 and the proposal in r1441707.
Comment 24 Kaspar Brand 2013-03-06 10:39:06 UTC
Fixed in 2.2.24 with r1445112.

As mentioned in the previous comment, it was originally fixed with 2.2.14, but then regressed and was broken in 2.2.15 through 2.2.23.