Bug 1670239
| Summary: | libpkix name constraints check treats CN as DNS name when it should not | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Fraser Tweedale <ftweedal> |
| Component: | nss | Assignee: | Daiki Ueno <dueno> |
| Status: | CLOSED ERRATA | QA Contact: | Alexander Sosedkin <asosedki> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 7.6 | CC: | amitkuma, asosedki, ddas, dueno, gparente, hkario, inikolch, mpanaous, msauton, nmavrogi, nss-nspr-maint, pkulkarn, rcritten, tmihinto, tscherf, yoliynyk |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | nss-3.43.0-2.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-23 10:35:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1645231 | ||
| Bug Blocks: | |||
Fix has been merged upstream: https://hg.mozilla.org/projects/nss/rev/db68b6975216 Moving to POST. This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable. The Apache, 389-ds and KDC certs are renewed by proxying through IPA using the cert-request command. The CA subsystem certificates are renewed directly against the CA. The error reported by certmonger is an SSL error coming out of curl and unfortunately it provides no details on the cause. It might help to try other tools to see if they provide additional details: curl -v --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key -d "serialNumber=1&xml=true" https://`hostname`:8443/ca/agent/ca/displayBySerial and openssl s_client -host `hostname` -port 8443 -cert /var/lib/ipa/ra-agent.pem -key /var/lib/ipa/ra-agent.key Once connected you'll need to type/paste this in: POST /ca/agent/ca/displayBySerial HTTP/1.1 Host: <the IPA master hostname> Content-Length: 23 Content-Type: application/x-www-form-urlencoded serialNumber=1&xml=true If they both succeed they'll return a big blob of cert output, the content of which is not important. These commands will exercise both the NSS and OpenSSL client libraries. (In reply to Rob Crittenden from comment #41) > The Apache, 389-ds and KDC certs are renewed by proxying through IPA using > the cert-request command. The CA subsystem certificates are renewed directly > against the CA. > > The error reported by certmonger is an SSL error coming out of curl and > unfortunately it provides no details on the cause. It might help to try > other tools to see if they provide additional details: > > curl -v --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key -d > "serialNumber=1&xml=true" https://`hostname`:8443/ca/agent/ca/displayBySerial > > and > > openssl s_client -host `hostname` -port 8443 -cert /var/lib/ipa/ra-agent.pem > -key /var/lib/ipa/ra-agent.key > If they both succeed they'll return a big blob of cert output, the content > of which is not important. These commands will exercise both the NSS and > OpenSSL client libraries. note though that the s_client will NOT abort the connection if it cannot verify server certificate one needs to look also for `Verify return code: 0 (ok)` in the s_client output Filed a new bug for the new issue: RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1737910 Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1571677 Hubert, thank you, you are correct and let me explain: I was using the vfychain program to perform verification. An NSSDB contains the constrained CA cert with trust 'CT,C,C', then I execute: [NSS_ENABLE_PKIX_VERIFY=1] /usr/lib64/nss/unsupported-tools/vfychain -d . -a ipara.pem The problem was I was not supplying '-u 0' to indicate client usage. Adding that flag, I observe that the legacy verifier succeeds and libpkix verifier fails. I will clarify this in mozbz:1571677. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:2237 |
How reproducible: always Steps to reproduce: 1. Have a CA with DNS name constraints permitted subtree. 2. Verify a certificate with an Extended Key Usage not containing id-kp-serverAuth (e.g. an OCSP signing certificate), whose Subject DN CN attribute does not resemble a DNS name within the permitted subtree. 3. Verify the certificate (using libpkix): NSS_ENABLE_PKIX_VERIFY=1 certutil -d $NSSDB -f $PWDFILE -V -e -n $NICKNAME -u O Actual results: Verification fails: # NSS_ENABLE_PKIX_VERIFY=1 certutil -d $NSSDB -f $PWDFILE -V -e -n $NICKNAME -u O certutil: certificate is invalid: The Certifying Authority for this certificate is not permitted to issue a certificate with this name. Expected results: Verification should succeed. The CN should not be treated as a DNS name unless the certificate being validated is a server authentication certificate (i.e. id-kp-serverAuth is asserted in the Extended Key Usage extension). For compatibility, it may be acceptable to continue treating CN as a DNS name if the certificate does not have the EKU extension. Version-Release number of selected component (if applicable): nss-3.36.0-7.el7_5.x86_64 (but AFAICT the bug is present in all currently supported versions, and upstream master). Additional info: I filed upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523484. Patch has been posted there.