When issuer Dn has a comma in it (or presumably other characters that reqiure escaping), certmap fails because a comparison between the stringified Issuer DN from the certificate, and the issuer DN from the certmap file, fails. For example, if the Issuer DN is:
CN=Certificate Authority,O="Acme, Inc.",ST=Massachusetts,C=US
This gets read from the certificate via the ldapu_get_cert_issuer_dn, which uses NSS' CERT_NameToAscii to return a stringified version of the DN. CERT_NameToAscii uses the RFC 1485 rules to serialise the DN, so the string looks like:
ldapu_get_cert_issuer_dn
CERT_NameToAscii
This string then gets processed by ldapu_dn_normalize which turns it into:
ldapu_dn_normalize
, which is wrong.
The comparison then fails when compared with the DN in the certmap.conf, which is properly escaped (a basic strcasecmp):
certmap.conf
strcasecmp
CN=Certificate Authority,O=Acme\, Inc.,ST=Massachusetts,C=US
v1.3.7
Bind fails, and doesn't even reach the internal search op for a user matching the certificate. (failure to match the issuer caused fallback to default certmap).
default
Bind succeeds, or at least uses the correct certmap such that internal search ops to look up a matching user are executed.
NSS stringifies DNs in the obsolete RFC 1485 format (https://bugzilla.mozilla.org/show_bug.cgi?id=355096).
We should avoid string DNs entirely. The issuer DN from certmap.conf should be parsed into 389's internal DN representation. The X.509 Issuer DN from the certificate should be directly converted into the same internal representation, without becoming a string. It may be possible to directly decode the DER-encoded Issuer DN from the cert.
Then these two internal representations should be compared by the appropriate function.
It is likely that the treatment of the Subject DN is also incorrect in the presence of commas, etc, because the certmap code also uses CERT_NameToAscii to read the Subject DN from the certificate (which is then used e.g. in the construction of a user search filter).
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.3.7.0
PR: https://pagure.io/389-ds-base/pull-request/49611
Downstream BZ
Metadata Update from @mreynolds: - Issue assigned to mreynolds
Metadata Update from @mreynolds: - Assignee reset - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
3800388..818807d 389-ds-base-1.3.8 -> 389-ds-base-1.3.8
9740c20..1a93d63 389-ds-base-1.3.9 -> 389-ds-base-1.3.9
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2602
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.