Closed Bug 1524879 Opened 11 months ago Closed 10 months ago

QuoVadis: IP in dnsName

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jonathan, Assigned: s.davidson)

Details

(Whiteboard: [ca-compliance])

QuoVadis issued the following certificates with invalid dnsNames containing IP addresses.

I notified them at 2019-01-29 17:53 UTC via an email to their problem reporting address (compliance@quovadisglobal.com) and did not receive a response. Only one of the reported certificates has been revoked.

https://crt.sh/?opt=zlint&id=42582447
https://crt.sh/?opt=zlint&id=42592375
https://crt.sh/?opt=zlint&id=42640525
https://crt.sh/?opt=zlint&id=183790885 (revoked)
https://crt.sh/?opt=zlint&id=282634800
https://crt.sh/?opt=zlint&id=483432106

QuoVadis acknowledge this report, and as observed with the first revocation above, are working with customers to replace these certificates. Will revert when complete.

Assignee: wthayer → s.davidson
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance]
  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.

We received an email from Jonathan Rudenberg on 1/29/2019 at 17.53 GMT.

  1. 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.

On 1/29/2019, we contacted the customers involved to inform of the issue and request accelerated replacement/revocation. On the morning of 2/4/2019, remaining certificates were revoked.

  1. 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.

The practice of issuing ipaddress in dnsname was halted in March 2018, but a decision was made to allow then existing certificates to expire naturally. At that time large numbers of similar certificates from many CAs were in use across the trusted SSL ecosystem.

  1. 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.

https://crt.sh/?opt=zlint&id=42582447
https://crt.sh/?opt=zlint&id=42592375
https://crt.sh/?opt=zlint&id=42640525
https://crt.sh/?opt=zlint&id=183790885 (revoked)
https://crt.sh/?opt=zlint&id=282634800
https://crt.sh/?opt=zlint&id=483432106

A review on 2/4/2019 has found additional certificates (<10) with the same issue. Efforts are underway to contact customers to replace and revoke these. This bug will be updated at that time.

  1. 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.

Above

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

Improvements were made to our certificate management system, without revoking previously issued certificates, particularly as understanding of the BR evolved through industry discussion.

  1. 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 issue was resolved in early 2018; these certificates are stragglers.

As noted in comment 2, a review of our earlier issuance identified 10 older (pre-CT) certificates with the same issue. Apologies for the delay in providing detail as I logged these in CT.

The following 8 certs were revoked:

https://crt.sh/?id=1206267633
https://crt.sh/?id=1206246349
https://crt.sh/?id=1206371485
https://crt.sh/?id=1206317671
https://crt.sh/?id=282646228
https://crt.sh/?id=1206332032
https://crt.sh/?id=282903484
https://crt.sh/?id=1206371602

The following two certificates will revoked by 2/22. The certificate holder, a Dutch Government Ministry, required additional time to make the replacement and it was believed that a rushed revocation posed a greater risk than the noncompliance.

https://crt.sh/?id=1206339175
https://crt.sh/?id=1206333491

We will confirm when these final two certificates have been revoked.

Whiteboard: [ca-compliance] → [ca-compliance] Next Update - 22-February 2019

Stephen: Jonathan's report indicated that Quovadis failed to meet the requirements of BR section 4.9.5:

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.

Is that correct? If so, please explain what happened and how it will be prevented as part of this incident report.

Also, per our updated best practices on revocation [1], please explain what Quovadis will do to prevent future revocation delays.

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

At this date there was an ongoing email thread between Jonathan and myself with the subject line "Problem report: invalid dnsName" relating to certificates we had already disclosed. I initially missed that this email with the subject line "Problem report: invalid dnsNames" dealt with a different set of certificates. My apologies.

Confirming the final two certificates were revoked on 2/20:

https://crt.sh/?id=1206339175
https://crt.sh/?id=1206333491

Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] Next Update - 22-February 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.