#4122 NSS sss_cert_get_content() fails on certificates without a subject
Closed: wontfix a year ago by orion. Opened a year ago by orion.

We are trying to workaround an issue with the way Windows clients cache certificates. See https://docs.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration#smart-card-sign-in-flow-in-windows for more info, but basically:

Note  Smartcard cache entries are created for certificates with a subject name or with a subject key identifier. If the certificate has a subject name, it is stored with an index that is based on the subject name and certificate issuer. If another certificate with the same subject name and certificate issuer is used, it will replace the existing cached entry. A change in this behavior after Windows Vista, allows for the condition when the certificate does not have a subject name, the cache is created with an index that is based on the subject key identifier and certificate issuer.

So, we would like to use certificates without a subject because the subject key identifier is unique for each certificate. However, certificates without a subject fail in the sss_certmap_match_cert() process because sss_cert_get_content() fails with a null subject:

    cont->subject_str = talloc_strdup(cont, cert->subjectName);
    if (cont->subject_str == NULL) {
        ret = ENOMEM;
        goto done;

perhaps this could be:

    if (cert->subjectName != NULL) {
        cont->subject_str = talloc_strdup(cont, cert->subjectName);
        if (cont->subject_str == NULL) {
            ret = ENOMEM;
            goto done;

I haven't yet tested the behavior of the openssl version of the code.

This is with sssd-1.16.4-21.el7.x86_64

Still doesn't work on Fedora 31 w/openssl, but with very different behavior. Filed issue #4123 for that.


you are right currently SSSD expects that the subject is set.

If read the related paragraphs of the X.509 spec, it says

If the public-key certificate is an end-entity public-key
certificate (see clause 7.4),
then the distinguished name may be an empty sequence
providing that the subjectAltName extension is present
and is flagged as critical (see clause Otherwise,
it shall be a non-empty distinguished name

So, subject may be empty. I think instead of using NULL in this case an empty string might be better, because this can be more easy handled the regular-expressions in matching rules.

Both the NSS build and the OpenSSL one currently expect a subject, so this ticket and #4123 are basically the same. Would you mind to close one of them?


I'm going to close this wontfix with the assumption that the NSS code is legacy at this point.

Metadata Update from @orion:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

a year ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/5083

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.

Login to comment on this ticket.