|Summary:||SSL_CLIENT_I_DN and SSL_CLIENT_S_DN use Email instead of emailAddress|
|Product:||Apache httpd-2||Reporter:||Sven Anders <s.anders>|
|Component:||mod_ssl||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Sven Anders 2009-06-18 00:33:24 UTC
Created attachment 23827 [details] ssl_emailaddress.patch When I look in the SSL_CLIENT_I_DN Variable I found: /C=DE/ST=Germany/L=Hamburg/O=Digitec/O=SES/OU=HAM/CN=Digitec Root CA (2048 bit)/Emailemail@example.com But this is not X509 Compaitble as mentioned in the RFCs. Correct would be: /C=DE/ST=Germany/L=Hamburg/O=Digitec/O=SES/OU=HAM/CN=Digitec Root CA (2048 bit)/firstname.lastname@example.org It would be very helpful if mod_ssl could export varibales like they are defined in RFC 2985 Standard. I have mad a patch for this, but perhabs it is better to create a new enviroment variable called SSL_CLIENT_I_DN_RFC2985 ?
Comment 1 Joe Orton 2009-06-23 07:26:48 UTC
There are various different standards for presenting a complete DN; LDAP has another. mod_ssl does not claim to (nor attempts to) meet any, it uses the OpenSSL legacy/default presentation format. Why does it matter what format is used here? It is not a parseable format.
Comment 2 Sven Anders 2009-09-10 02:23:49 UTC
Hi Joe, there is a module called mod_authz_ldap. As it is not developed anymore, my company is planning to do a fork this product to make it usable to apache 2.2. (URL of the old project page is: http://authzldap.othello.ch/ ) The module is using the following openssl funtions for getting the stings for the issuer and the subject: * X509_get_issuer_name(x) * X509_get_subject_name(x) This functions are implemented to conform to RFC 2985. mod_ssl is using openssl, but does some things different from every other standard I know. If I look to the pem file of a certificate I find: Signature Algorithm: md5WithRSAEncryption Issuer: C=DE, ST=Germany, L=Hamburg, O=digitec GmbH, O=digitec, OU=Secure Enterprise Service, CN=Digitec Root CA (2048 bit)/emailAddressemail@example.com .. Subject: C=DE, ST=Germany, L=Hamburg, O=digitec GmbH, O=digitec, OU=Secure Enterprise Services, CN=Sven Anders [san]/emailAddressfirstname.lastname@example.org DirName:/C=DE/ST=Germany/L=Hamburg/O=digitec GmbH/O=digitec/OU=Secure Enterprise Service/CN=Digitec Root CA (2048 bit)/emailAddressemail@example.com Everywhere emailaddress= (not Email=) is used. Can you give me an example of standards where EMail= is used? Best Regards Sven Anders
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:23 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.