Bugzilla

(In reply to Youfu Zhang from comment #5)
> The scope of this mis-issuance incident appears to be broader than the initially reported certificates for the IP addresses `1.1.1.1` and `2.2.2.2`. [As noted by Wayne in the dev-security-policy mailing list on September 5, 2025](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SgwC1QsEpvc/m/bjcJWe0VAAAJ), several other non-compliant certificates have been discovered.
> 
> ### **Categories of Mis-issuance**
> 
> The additional certificates fall into three main categories:
> 
> * **Reserved IP Addresses:** Certificates issued with an iPAddress SAN entry containing a reserved (private) IPv4 address (e.g., from the `10.0.0.0/8` block).
> * **Internal Names:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains an Internal Name (e.g., a bare hostname without a TLD).
> * **Non-LDH Labels:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains a label with non-LDH characters (e.g., spaces or underscores).
> 
> As of today (2025-09-19), these certificates have not yet been revoked.
> 
> ### **Violation of Baseline Requirements**
> 
> This issuance is a clear violation of the CA/Browser Forum's TLS Baseline Requirements (v2.1.7), including:
> 
> * **Section 4.2.2**, which prohibits CAs from issuing certificates containing Internal Names or Reserved IP Addresses.
>   > CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.
> * **Section 7.1.2.7.12**, which states that dNSName SAN entries must not contain Internal Names and must be composed of LDH labels.
>   > The entry MUST NOT contain an Internal Name.
>   > The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (“.”) character.
> * **Section 7.1.4.3**, which mandates that all domain labels within Subject CommonName must be encoded as LDH labels.
>   > Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
> 
> ### **Questions for Fina**
> 
> Given this new information, I have the following questions:
> 
> 1.  Why were these additional categories of non-compliant certificates omitted from the incident report? Was Fina's investigation limited only to the `1.1.1.1` and `2.2.2.2` certificates?


> 2.  What steps is Fina now taking to perform a comprehensive search for all other certificates that may violate the Baseline Requirements in similar ways?

(In reply to Youfu Zhang from comment #5)
> The scope of this mis-issuance incident appears to be broader than the initially reported certificates for the IP addresses `1.1.1.1` and `2.2.2.2`. [As noted by Wayne in the dev-security-policy mailing list on September 5, 2025](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SgwC1QsEpvc/m/bjcJWe0VAAAJ), several other non-compliant certificates have been discovered.
> 
> ### **Categories of Mis-issuance**
> 
> The additional certificates fall into three main categories:
> 
> * **Reserved IP Addresses:** Certificates issued with an iPAddress SAN entry containing a reserved (private) IPv4 address (e.g., from the `10.0.0.0/8` block).
> * **Internal Names:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains an Internal Name (e.g., a bare hostname without a TLD).
> * **Non-LDH Labels:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains a label with non-LDH characters (e.g., spaces or underscores).
> 
> As of today (2025-09-19), these certificates have not yet been revoked.
> 
> ### **Violation of Baseline Requirements**
> 
> This issuance is a clear violation of the CA/Browser Forum's TLS Baseline Requirements (v2.1.7), including:
> 
> * **Section 4.2.2**, which prohibits CAs from issuing certificates containing Internal Names or Reserved IP Addresses.
>   > CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.
> * **Section 7.1.2.7.12**, which states that dNSName SAN entries must not contain Internal Names and must be composed of LDH labels.
>   > The entry MUST NOT contain an Internal Name.
>   > The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (“.”) character.
> * **Section 7.1.4.3**, which mandates that all domain labels within Subject CommonName must be encoded as LDH labels.
>   > Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
> 
> ### **Questions for Fina**
> 
> Given this new information, I have the following questions:
> 
> 1.  Why were these additional categories of non-compliant certificates omitted from the incident report? Was Fina's investigation limited only to the `1.1.1.1` and `2.2.2.2` certificates?
At the first step investigation was initially focused on the 1.1.1.1 and 2.2.2.2 test certificates because we considered this case to be the most important case due to the possible threat, so the incident report was focused to these certificates. Additional categories of non-compliant certificates are also included in the next step of investigation as for1.1.1.1 and 2.2.2.2 test certificates.

> 2.  What steps is Fina now taking to perform a comprehensive search for all other certificates that may violate the Baseline Requirements in similar ways?
We are investigating certificates that have any of the categories of reported errors in the SAN extension: certificates that contain Reserved IP address, Internal Names or labels with non-LDH characters in the SAN extension. Also, we are performing in-depth analyses and checks of the causes that led to the errors in the process of verifying this data and issuing a certificate

(In reply to Youfu Zhang from comment #5)
> The scope of this mis-issuance incident appears to be broader than the initially reported certificates for the IP addresses `1.1.1.1` and `2.2.2.2`. [As noted by Wayne in the dev-security-policy mailing list on September 5, 2025](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SgwC1QsEpvc/m/bjcJWe0VAAAJ), several other non-compliant certificates have been discovered.
> 
> ### **Categories of Mis-issuance**
> 
> The additional certificates fall into three main categories:
> 
> * **Reserved IP Addresses:** Certificates issued with an iPAddress SAN entry containing a reserved (private) IPv4 address (e.g., from the `10.0.0.0/8` block).
> * **Internal Names:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains an Internal Name (e.g., a bare hostname without a TLD).
> * **Non-LDH Labels:** Certificates issued where the Subject CommonName or a dNSName SAN entry contains a label with non-LDH characters (e.g., spaces or underscores).
> 
> As of today (2025-09-19), these certificates have not yet been revoked.
> 
> ### **Violation of Baseline Requirements**
> 
> This issuance is a clear violation of the CA/Browser Forum's TLS Baseline Requirements (v2.1.7), including:
> 
> * **Section 4.2.2**, which prohibits CAs from issuing certificates containing Internal Names or Reserved IP Addresses.
>   > CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.
> * **Section 7.1.2.7.12**, which states that dNSName SAN entries must not contain Internal Names and must be composed of LDH labels.
>   > The entry MUST NOT contain an Internal Name.
>   > The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (“.”) character.
> * **Section 7.1.4.3**, which mandates that all domain labels within Subject CommonName must be encoded as LDH labels.
>   > Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.
> 
> ### **Questions for Fina**
> 
> Given this new information, I have the following questions:
> 
> 1.  Why were these additional categories of non-compliant certificates omitted from the incident report? Was Fina's investigation limited only to the `1.1.1.1` and `2.2.2.2` certificates?

At the first step investigation was initially focused on the 1.1.1.1 and 2.2.2.2 test certificates because we considered this case to be the most important case due to the possible threat, so the incident report was focused to these certificates. Additional categories of non-compliant certificates are also included in the next step of investigation as for1.1.1.1 and 2.2.2.2 test certificates.

> 2.  What steps is Fina now taking to perform a comprehensive search for all other certificates that may violate the Baseline Requirements in similar ways?

We are investigating certificates that have any of the categories of reported errors in the SAN extension: certificates that contain Reserved IP address, Internal Names or labels with non-LDH characters in the SAN extension. Also, we are performing in-depth analyses and checks of the causes that led to the errors in the process of verifying this data and issuing a certificate

[edited by dveditz to separate response from quoted matter]