Bug 35154 - Support for NID_serialNumber, etc. in SSLUserName
Summary: Support for NID_serialNumber, etc. in SSLUserName
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.54
Hardware: All All
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
Depends on:
Blocks:
 
Reported: 2005-06-01 12:17 UTC by Marc Stern
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments
Support for NID_serialNumber in SSLUserName (849 bytes, patch)
2005-06-01 15:19 UTC, Marc Stern
Details | Diff
Port to 2.2.4 (735 bytes, patch)
2007-01-25 04:44 UTC, Marc Stern
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Stern 2005-06-01 12:17:44 UTC
The SSUserName directive does not support the field 'NID_serialNumber'.
This field is commonly used for the official unique id in national identity
certificates; it would really help to add it.

I tried to add the line
    { LN_serialNumber, NID_serialNumber   },
in ssl_var_lookup_ssl_cert_dn_rec[] (ssl_engine_var.c), but it doesn't work.

I also added
    "SSL_CLIENT_S_DN_serialNumber",
in ssl_hook_Fixup_vars[] (ssl_engine_kernel.c), but it doesn't help either.
Comment 1 Marc Stern 2005-06-01 14:08:00 UTC
Sorry, by adding both entries it works.

Btw, several European countries use this field to store the national identity
number: Belgium, Estonia, Finland, etc.
Comment 2 Joe Orton 2005-06-01 14:29:07 UTC
The name should be using the short (SN_) not the long variant and I'd rather not
rely on OpenSSL's SN_ definition since if that changes mod_ssl would break
compatibility.

So a patch to add { "SN", ... } and the CLIENT_S_DN_SN would be OK.  Please
attach diff -u format patches, not code which has to be cut'n'pasted!
Comment 3 Marc Stern 2005-06-01 15:17:34 UTC
"SN" is "surname".
No short name for "serialNumber" is defined in OpenSSL, is that a real problem ?
Comment 4 Marc Stern 2005-06-01 15:19:01 UTC
Created attachment 15246 [details]
Support for NID_serialNumber in SSLUserName
Comment 5 Marc Stern 2007-01-09 06:38:16 UTC
Solved in 2.2
Comment 6 Marc Stern 2007-01-09 08:27:28 UTC
Sorry, a mistake.
It's not fixed.
Comment 7 Marc Stern 2007-01-25 04:44:23 UTC
Created attachment 19458 [details]
Port to 2.2.4
Comment 8 Bob Ionescu 2007-01-25 15:24:15 UTC
Please don't change the assignee filed, this breaks changes to be send to the
bugs@ mailing list.
Comment 9 Peter Sylvester 2009-07-19 23:50:13 UTC
rfc 5280 says

   Standard sets of attributes have been defined in the X.500 series of
   specifications [X.520].  Implementations of this specification MUST
   be prepared to receive the following standard attribute types in
   issuer and subject (Section 4.1.2.6) names:

      * country,
      * organization,
      * organizational unit,
      * distinguished name qualifier,
      * state or province name,
      * common name (e.g., "Susan Housley"), and
      * serial number.

   In addition, implementations of this specification SHOULD be prepared
   to receive the following standard attribute types in issuer and
   subject names:

      * locality,
      * title,
      * surname,
      * given name,
      * initials,
      * pseudonym, and
      * generation qualifier (e.g., "Jr.", "3rd", or "IV").


"Being prepared" IMO opinion means for a replying party like mod_ssl and its users to facilitate the usage.
Comment 10 William A. Rowe Jr. 2018-11-07 21:09:13 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.