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 SSL_CLIENT_S_DN_UID: (none) 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 2.5.4.45). I consider this to be seriously broken because the syntax assigned to attribute type 'x500UniqueIdentifier' (OID 2.5.4.45) is 'Bit String' (OID 1.3.6.1.4.1.1466.115.121.1.6) which cannot be used to store a user ID with characters like 'ABCDEF'. See also http://www.alvestrand.no/objectid/2.5.4.45.html 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.
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.