#49543 certmap fails when Issuer DN has comma in name
Closed: wontfix 5 years ago Opened 6 years ago by ftweedal.

Issue Description

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:

CN=Certificate Authority,O="Acme, Inc.",ST=Massachusetts,C=US

This string then gets processed by ldapu_dn_normalize which turns it into:

CN=Certificate Authority,O="Acme, Inc.",ST=Massachusetts,C=US

, which is wrong.

The comparison then fails when compared with the DN in the certmap.conf, which
is properly escaped (a basic strcasecmp):

CN=Certificate Authority,O=Acme\, Inc.,ST=Massachusetts,C=US

Package Version and Platform


Steps to reproduce

  1. configure a certmap with an issuer that has comma in a name.
  2. attempt certificate bind with valid certificate issued by the certmap issuer.

Actual results

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

Expected results

Bind succeeds, or at least uses the correct certmap such that internal search ops to look
up a matching user are executed.

Notes on proposed fix

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.

Related issues

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:

6 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

5 years ago

Metadata Update from @mreynolds:
- Assignee reset
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Log in to comment on this ticket.