Bug 45107

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

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.

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.

*** Bug 29201 has been marked as a duplicate of this bug. ***

Discussion thread, for reference:

http://marc.info/?l=apache-modssl&m=121118489703295&w=2

Committed in r787683.

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 */
#else
        #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
#endif

start working

Can someone provide a non working cert and the values of both
SSL_CLIENT_S_DN and SSL_CLIENT_S_DN_UID.

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

openssl.cnf:

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


and cert:

-----BEGIN CERTIFICATE-----
MIIEvjCCAqagAwIBAgIBBTANBgkqhkiG9w0BAQUFADCBijELMAkGA1UEBhMCQ1ox
GDAWBgNVBAgTD0Nlc2thIFJlcHVibGlrYTEOMAwGA1UEBxMFUHJhaGExFTATBgNV
BAoTDFNhbnRlIHMuci5vLjEZMBcGA1UEAxMQTUFYIHYxIENsaWVudCBDQTEfMB0G
CSqGSIb3DQEJARYQc3VwcG9ydEBzYW50ZS5jejAeFw0wOTA4MjcxNjU4MjdaFw0x
MDA4MjcxNjU4MjdaMIHDMQswCQYDVQQGEwJDWjEOMAwGA1UECBMFU3RhdGUxETAP
BgNVBAcTCExvY2F0aW9uMRUwEwYDVQQKEwxPcmdhbml6YXRpb24xEjAQBgNVBAsT
CVRlc3QgVW5pdDESMBAGA1UEAxMJVGVzdCBVc2VyMRwwGgYJKoZIhvcNAQkBFg10
ZXN0QHRlc3QuY29tMTQwMgYKCZImiZPyLGQBARMkZDFiZmYzNzYtMzc4OC00MDRm
LWFlOWMtZmZmZmZmZmZmZmZmMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDM
1V8TAu3mfzXduSI6fZcbT00mbZjOuvBBn+SAKnSn0Evf/x3qzfzRcG3fyXrOICnF
A66R9Dm3SGyuhr7SnWSrOtezAUkOsBejke2tdElk7OgoXQQHblBAKFGcJ7yeKxdy
+nk9CGvXV1SaLJYU+DOAQt1h6qaHbi8+soRtJWs8CwIDAQABo3gwdjAMBgNVHRMB
Af8EAjAAMBEGCWCGSAGG+EIBAQQEAwIHgDALBgNVHQ8EBAMCB4AwEwYDVR0lBAww
CgYIKwYBBQUHAwIwMQYJYIZIAYb4QgENBCQWIk9wZW5TU0wgQ2VydGlmaWNhdGUg
Zm9yIFNTTCBDbGllbnQwDQYJKoZIhvcNAQEFBQADggIBAE1a/t72msEM69N/k6hw
pBAc3hHQKlcmM+jSX5RhuuQEJu3iKf9OeExULZnBhBK1VhwEcYKOP3On/fbFC/Hi
LVawkt4S67bgxCzVSiHiEp7vJpoPBRH1ifZO5TzbXsKrGjN6zNy9zSS7QFWE0hy6
dtX0Jjx8iU3c46+E+R5OK6nlbcLXIh6DYXSZgo0FdeF+m9unQoE34TRe9imbh8ZF
6e4noXEYAna9sVEMQDvGKycC7HJaltV/iS44UXji0uvUA31sUfhEbGAlGxw3DhXr
HQAhv7xQ4QICzGANtF/Tic4zi+KNvWtGZ+MtOWxkcLgxc13Vhr+Hp1d+cGWMj9A3
xRjeW5DK1DVBjI8dAb1B14lCYrd4sXZbSDH2YhbXAw6PILN7hmrauJTIlMyz8LEn
AKcIxlR59QaimZgfiN9c0gV4QKHAUO+seHGIa9/1ewZ1vidbGyldpCojbbfMnCX6
cPISe+fIl8h5Ph81iRYNGiT6dqoHk3OHhw2PtXSCDieN5qZrqBigaDnRQ9awWbnK
l2m19MBVaE7VtPCmqrqLH+uTqepFFspBs29AFHXiSw4L0aGicuaduSyZ5XpZ0xN3
ojDfBQYTmcafwmfyDDi2YsNJqCgJJLMmYo5eIklt3sgKypCs6NwJGl18Wgcv1WRO
4YOTATlUek/SuqnvIVl4Fv4A
-----END CERTIFICATE-----

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)

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       },
        #endif

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

/usr/include/openssl/objects.h:
....
#define SN_uniqueIdentifier             "UID"
#define LN_uniqueIdentifier             "uniqueIdentifier"
#define NID_uniqueIdentifier            102
#define OBJ_uniqueIdentifier            OBJ_X509,45L
...


/usr/include/openssl/obj_mac.h:
...
#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,2.5.4.3=Test User,2.5.4.11=Test Unit,2.5.4.10=Organization,2.5.4.7=Location,2.5.4.8=State,2.5.4.6=CZ

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 2.5.4.45? 

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 2.5.4.45
anyway.

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 2.5.4.45?

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)

The patch should be backported as soon as possible so
that packaged standard versions get it.

great, i hope that will be in next release (2.2.14)

thank you

This issue was fixed in 2.2.x branch with r811812 and will ship with httpd 2.2.14.

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 },
#endif

instead:
+ #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

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).

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.

Michael,

I'm sorry.  That is a Ubuntu's backward compatibility problem, not apache's.
I agree with you that using userId is appropriate.

Create a new bugzilla entry if you think there's followup work to do here.

I think comment 16 was overlooked in the ubuntu backward compatibility debate.

It looks like:
http://svn.apache.org/viewvc?view=revision&revision=910319
 #ifdef NID_userId
-    { "UID",   NID_userId                 },
+    { "UID",   NID_x500UniqueIdentifier,   1 },
 #endif

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.

I opened bug 54510 to report the regression noted in Comment 16

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.

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.