1937392 - mozilla::pkix: consider reversing empty SAN compatibility workaround added in bug 1143085

Status: NEW

(NSS :: Libraries, enhancement, P5)

Description

[2295456556]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0

Steps to reproduce:

1. Adding the root cert to the certificate store using certutil.(certutil -addstore root _root_A_12.124.150.34.der)
2. Using Nginx with a certificate file named chain.crt and a file named server_key.pem
3. Setting up the local machine (127.0.0.1) as the server and mapping "ypj.test.com" to 127.0.0.1 in the hosts file
4. Running nginx.exe and accessing the URL "https://ypj.test.com:443" in a web browser, where the certificate's SAN matches the URL.

Actual results:

We have observed an issue where a certificate chain containing multiple Certificate Authorities (CAs) with empty Subject Alternative Names (SANs) fields still passes browser verification.

Actual Behavior:
Firefox: Successfully validates the certificate chain despite the presence of empty SAN extensions in multiple CA certificates.
Chrome: Correctly identifies the issue with the SAN extensions being empty in the CA certificates, including the root, and fails the validation process, preventing connection or access.

Expected results:

This discrepancy allows Firefox users to connect to servers with potentially insecure or incorrectly configured certificates, which could lead to security vulnerabilities if not addressed. Both browsers should reject the certificate chain.

Comment 1

[2295456556]

Attachment: chain.crt

Comment 2

[2295456556]

Attachment: server_key.pem

Comment 3

[2295456556]

Attachment: _root_A_12.124.150.34.der

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 5

[2295456556]

This file(chain.crt) contains five PEM certificates in the following order:
End-entity certificate (end)
Intermediate Certificate 1 (inner1)
Intermediate Certificate 2 (inner2)
Intermediate Certificate 3 (inner3)
Intermediate Certificate 4 (inner4) Each certificate in the chain is correctly signed by the next certificate in the sequence (e.g., end is signed by inner1, inner1 is signed by inner2, and so forth until inner4).

Comment 6

[Ben Wilson]

Intermediate CAs are not required to have SANs. See https://cabforum.org/working-groups/server/baseline-requirements/requirements/#71261-tls-subordinate-ca-extensions

Comment 7

[2295456556]

First, as you mentioned, the CA/Browser Forum's specifications state that intermediate CAs are not required to have SANs. In section 7.1.2.6.1 TLS Subordinate CA Extensions of the specifications, "Any other extension" is marked as "NOT RECOMMENDED". It is clear that the CA/Browser Forum also leans towards not using CA certificates with SANs.

Secondly, I want to illustrate the potential verification issues brought by the CA certificate with Empty SAN through the following example:
Assuming there is a certificate chain [end, inner, root], where the root certificate's Name Constraints allow for an RFC822 Name=hello.com; the intermediate certificate's subject field contains an Email = [e-mail], and the SAN field is empty. For this empty SAN, there is only an OID indicating the presence of SAN, but it carries no meaningful information. The current situation can be summarized as follows:
1. If Name Constraints are enforced, then E = [e-mail] should not be allowed to appear.
2. Should an empty SAN node be considered as existing or non-existing? If it's treated as non-existing, but the SAN OID is indeed present; if it's treated as existing, but it carries no useful information, it is essentially the same as not existing.
3. According to RFC5280: "When constraints are imposed on the rfc822Name name form, but the certificate does not include a subject alternative name, the rfc822Name constraint MUST be applied to the attribute of type emailAddress in the subject distinguished name."

For this scenario, Firefox handles it as follows: Because Firefox does not consider an empty SAN in a CA certificate as an error, it treats this empty SAN as "existing", thus allowing the validator to bypass the Name Constraints on the Subject-Email, ultimately passing the validation.

I believe this is incorrect, and the handling should be as follows: Although the SAN exists, since it is empty, it is essentially the same as not existing, and the CA/Browser Forum has also marked it as "NOT RECOMMENDED". I think we should choose one of the following approaches:
1. Like Chrome, perform strict format checking and directly reject the certificate as invalid for cases where SAN is empty, which neither conforms to real-world practices nor is supported by the CA/Browser Forum.
2. Even if not rejecting, do not treat an empty SAN as "existing", but rather as 'non-existing'. In the current situation, Firefox considers the SAN as existing, which directly bypasses the Name Constraints on the Subject-Email, reversing the validation result, which I believe is entirely unacceptable. Chrome, on the other hand, does well by strictly rejecting intermediate CA certificates with empty SANs, avoiding such validation result reversal and adhering strictly to the CA/Browser Forum's specifications.

If we consider an empty SAN as "existing", then I believe this is a form of self-deception. Although we do not have strict specifications on how to handle empty SANs, I think we should not rely entirely on specifications; in the absence of specifications, we should follow rational human logic to handle the situation.

Supplement: I will upload new files [end_.der, inner_.der, root_.der, server_key_.pem]. As I mentioned above, in the new files, due to the presence of an empty SAN, Firefox bypasses the Name Constraints on the Subject-Email and passes the validation.

Comment 8

[2295456556]

Attachment: end_.crt

Comment 9

[2295456556]

Attachment: end_.der

Comment 10

[2295456556]

Attachment: inner0_.der

Comment 11

[2295456556]

Attachment: root_.der

Comment 12

[2295456556]

Attachment: server_key_.pem

Comment 13

[2295456556]

If the root certificate's Name Constraints allow for an RFC822 Name=hello.com, and simultaneously the intermediate certificate's subject field contains an Email = [e-mail] and the SAN field does not exist, in such a case, Firefox will perform the Name Constraints check well and display SEC_ERROR_CERT_NOT_IN_NAME_SPACE, rather than bypassing the Name Constraints check due to an empty SAN as reported.

If the developers need such a test case, please let me know, and I can generate and upload it

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Empty SANs were allowed for compatibility reasons in bug 1143085. If Chrome now rejects them, we may be able to remove the workaround as well.

In the meantime, however, I think treating empty SANs as "present, but with irrelevant information" is reasonable. After all, if you replace the empty SANs with one containing a single otherName entry, name constraint processing wouldn't fall back to the subject distinguished name and verification would succeed, right?

Comment 15

[2295456556]

Firstly, Chrome rejects certificates with an empty SAN, indicating that Chrome has stricter checks for empty SANs.

Secondly, as you've mentioned, whether the SAN is empty or non-empty, the name constraints will not restrict the email in the subject and the verification would still pass. However, I still think there are some problems:
1. Potential Misconfiguration: Although an empty SAN might be viewed as a statement that the certificate is not applicable to any specific name, the possibility of this being a misconfiguration cannot be ruled out. In such cases, checking the emailAddress can serve as an additional security measure. Therefore, I believe that even if we don't outright reject CA certificates with an empty SAN, in the presence of an rfc822Name constraint, we should check the emailAddress.
2. Flexible Use of RFC5280: RFC5280 mentions that the emailAddress should be checked when the SAN does not exist, but the rfc822Name constraint is present. I believe the intention here is to provide an alternative verification path in the absence of SAN entry information. For both cases where the SAN is empty or does not exist, essentially we are not getting any SAN entry information to use for verification, and in such a scenario, we should utilize another verification path to ensure the completeness of the verification.
3. One-size-fits-all Rejection: Adopting a one-size-fits-all approach by outright rejecting CA certificates with an empty SAN not only better aligns with the CA/Browser Forum guidelines but also brings our certificate checking in line with practices like those of Chrome, making certificate checks more stringent. This also avoids controversy
In summary, accepting such a certificate chain, in my opinion, is unreasonable. RFC5280 states that when an rfc822Name constraint exists and the SAN does not exist, the emailAddress must be checked. However, it does not specify that if an rfc822Name constraint exists and the SAN is present, the emailAddress must not be checked. In this case, performing the emailAddress check is also compliant with the standard, especially since an empty SAN is more akin to the SAN not existing at all, and is far from being considered as "SAN exists."

Comment 16

[Ben Wilson]

I'd like to clear up any confusion here between SAN requirements for CA certificates and TLS end-entity certificates. SANs are required for TLS end-entity certificates used in the Web PKI because they are used for hostname validation during TLS connections. However, this requirement does not extend to CA certificates. CA certificates are primarily used to sign other certificates, and their validation relies on the Issuer and Subject fields. I do not believe that there is a requirement in RFC 5280, the TLS Baseline Requirements, or in Chrome for CA certificates to include a SAN. The examples being discussed about RFC822 names in the SANs of name-constrained CAs do not make sense to me. Can you be more specific about your concerns as they relate to the Web PKI, or are your concerns focused on the path validation when there is a name-constrained CA that issues S/MIME certificates?

Comment 17

[2295456556]

Thank you for clarifying the distinction between SAN requirements for CA certificates and TLS end-entity certificates. Here's how I would respond to your points:

1. Web PKI and SAN Requirements: You're correct in stating that SANs are primarily used for hostname validation in TLS end-entity certificates. However, my concerns are not about the requirement for SANs in CA certificates per se, but rather about how name constraints, particularly rfc822Name constraints, interact with certificate validation processes, especially in contexts beyond just Web PKI.

2. RFC 5280 and Name Constraints: While RFC 5280 does not explicitly require SANs for CA certificates, it does discuss how name constraints are applied. Specifically, when an rfc822Name constraint is present in a CA certificate, it mandates that the emailAddress in the subject of the cert must be checked if there is no SAN. My concern is about the interpretation of this rule when the SAN in a CA certificate is present but empty.

3. Path Validation with Name-Constrained CAs: My focus is indeed on path validation, particularly when dealing with name-constrained CAs that issue certificates for purposes other than TLS, like S/MIME. In such cases, if a CA has an rfc822Name constraint and the SAN is empty, it seems reasonable to check the emailAddress in the subject of the certificate issued by this CA. This approach aligns with the spirit of RFC 5280's intent to provide an alternative verification path when SAN information is not available or not applicable.

4. Security and Flexibility: My argument is for enhancing security by ensuring that even in cases where the SAN is present but empty, there's still a fallback validation mechanism (checking emailAddress) to prevent potential misconfiguration or attacks. This isn't about mandating SANs in CA certificates but about ensuring robust validation processes.

5. Chrome's Behavior: I mentioned Chrome's rejection of certificates with empty SANs as an example of how strict validation can be applied, not to imply that CA certificates should have SANs. However, the principle of strict validation could be applied in a similar manner to ensure the security of the entire certificate chain, including how name constraints are handled.

In summary, my concerns are not about requiring SANs in CA certificates but about ensuring that name constraints are applied correctly and securely, especially in scenarios where SANs might be present but empty or not applicable, to maintain the integrity and security of the certificate validation process across different use cases, including but not limited to Web PKI.

Comment 18

[2295456556]

Please let me know if you will further investigate this issue and consider updating the current bug report's status. This is very important for my work. Thanks again!

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler]]

We don't really use the status field for much except when it's changed to "resolved", but if it matters to you, I've set it to "new".