1530623 - QuoVadis: IPaddress in DNSname SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Stephen Davidson]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

Steps to reproduce:

Our post issuance linting noted that today we issued a certificate with an IP address in DNSname SAN field:

https://crt.sh/?id=1228598409

The certificate will be revoked today, and a report filed on how this occurred.

Comment 1

[Stephen Davidson]

The certificate was revoked on 2019-02-26 at 10:49:09 UTC. Report to follow.

Comment 2

[Stephen Davidson]

For the sake of clarity, this is related to the same issue covered in a previous bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1524879
A full disclosure report to follow.

Comment 3

[Stephen Davidson]

Thank you for your patience. Attached is our report relating to the miss-issuance of a certificate with an IP addresses in a dNSName SAN field.

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Our post issuance linting alerted us of the certificate on 2019-02-26 at 00:00:00 UTC.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

A request was made to the certholder to revoke the certificate. Revocation occurred on 2019-02-26 at 10:49:09 UTC.

An investigation was commenced to ascertain if other valid certificates exist with the same issue; it was confirmed there are none.

An investigation was commenced to ascertain how the certificate came to be issued with an IP address in a DNS name field in SAN.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

We have redeveloped our approach to ensuring IP addresses are tagged as such in TLS. The new approach has been tested and will be implemented across all TLS production CAs by Mar 20, 2019 at the latest.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

The identified certificate was: https://crt.sh/?id=1228598409&opt=cablint

However the same issue was previously discussed in another bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1524879

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=1228598409&opt=cablint

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Previously the enforcement in this area was divided between our certificate management system (CMS) and the CA. During approval workflows in the CMS, entries are tagged as format iPAddress or dNSName. The CA will not allow entries tagged as iPAddress to go into a dNSName SAN field.

The issue arose in a particular workflow in our CMS, an Administrator was able to mistakenly tag an entry containing an IP address as a dNSName. The new rule is more rigorous:

• Does not allow an entry containing an IP address to be tagged as a dNSName, and vice versa, in the CMS. This applies to all workflows.
• A pre-issuance lint confirms that SAN fields containing an IP address are in the iPAddress format.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The new approach has been tested and will be implemented across all TLS production CAs by Mar 20, 2019 at the latest. As previously advised, we implemented our own post-issuance linting tool in 2018 to be able to monitor external subCAs more effectively. We have limited preissuance linting for some technical features of keys and certificates. We are currently testing a broader pre-issuance linting tool that will be implemented across all QuoVadis TLS-issuing CAs before June 2019.

Comment 4

[Stephen Davidson]

Pre-issuance linting has been implemented for QuoVadis trusted TLS policies effective April 16, 2019.
I think this resolves this bug.

Comment 5

[Wayne Thayer]

It appears that remediation is complete.