Learn more about these different git repos.
Other Git URLs
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.
Hi,
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 9.3.2.1). 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.
NULL
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?
bye, Sumit
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.