1524195 - Asseco DS / Certum: Invalid dnsNames

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wojciech Trapczyński]

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

Actual results:

We received email from Mr. Jonathan Rudenberg on January 30 with list of unexpired and unrevoked SSL certificates with invalid dNSName in SAN:

https://crt.sh/?opt=zlint&id=13087593
https://crt.sh/?opt=zlint&id=16177837
https://crt.sh/?opt=zlint&id=20439645
https://crt.sh/?opt=zlint&id=57608191
https://crt.sh/?opt=zlint&id=68194677
https://crt.sh/?opt=zlint&id=102050109
https://crt.sh/?opt=zlint&id=103359040
https://crt.sh/?opt=zlint&id=108269205
https://crt.sh/?opt=zlint&id=113860047
https://crt.sh/?opt=zlint&id=150702035
https://crt.sh/?opt=zlint&id=154786555
https://crt.sh/?opt=zlint&id=282640864
https://crt.sh/?opt=zlint&id=282660693
https://crt.sh/?opt=zlint&id=282908416
https://crt.sh/?opt=zlint&id=282908722
https://crt.sh/?opt=zlint&id=282909346
https://crt.sh/?opt=zlint&id=1130552559

The problem was that we issued certificates with IP address in SAN dNSName. The problem concerned certificates issued before June 2017. Since June 2017 we do not issue certificates with IP address in SAN dNSName.

I will send the incident report soon.

Comment 2

[Wojciech Trapczyński]

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 email from Mr. Jonathan Rudenberg on January 30, 2019.

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.

May 31, 2017 11:40 UTC – We stopped issuing certificates with IP address in Subject Alternative Name dNSName. We decided not to revoke those certificates and allowed them to expire.
Jan 30, 2019 12:49 UTC – We received email from Mr. Jonathan Rudenberg with list of unexpired and unrevoked SSL certificates with invalid dNSName in SAN.
Jan 30, 2019 15:00 UTC – We decided to change our original decision and revoke those certificates to in order to follow current recommendation.
Jan 30, 2019 16:00 UTC – We started sending notification about this issue to customers.
Jan 31, 2019 08:44 UTC – We created this bug (number 1524195).

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 stopped issuing certificates with IP address in Subject Alternative Name dNSName on May 31, 2017.

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.

37 certificates.
First certificate notBefore date: Jan 31 00:00:00 2016 UTC.
Last certificate notBefore date: May 23 12:36:42 2017 UTC.

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.

In an attached certs.pem file.

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

We were issuing such certificates because placing IP address just in SAN iPAddress make them unusable in some browsers.

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.

We decided to revoke all certificates containing IP address in SAN dNSName. We sent to our customers explanation about this issue and we informed them about the necessity of revocation theirs certificates. Some of them informed us that they need some more time to replace certificate. Considering that this issue is not a great security threat and having in mind our previous decision (about not revoking certificates) we decided to give them, as an exception, 10 days more to complete replacement. Until February 15, 2019 14:00 UTC all those certificates will be revoked.

Comment 3

[Wojciech Trapczyński]

Attachment: certs.pem

Comment 4

[Wojciech Trapczyński]

All those certificates were revoked.

Comment 5

[Wayne Thayer]

Wojciech: Please be aware that Mozilla best practices have been updated and now explicitly state that "this issue is not a great security threat" is not an acceptable explanation for failing to meet the BR revocation deadlines: https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

Have you notified your auditor of this violation?
Please describe what Certum will do to ensure that exceptions to the BR revocation deadline will not be needed in the future?

Comment 6

[Wojciech Trapczyński]

As I mentioned we decided to delay revocations on basis our previous decision about not revoking those certificates at all. Additional reason was feedback from our customers. Some of them come from China and at that time they were celebrating Chinese New Year. They could not replace certificates in easy way and revocations could interrupt working their production systems. The combination of these two factors made us make that decision.

We have treated this case as an exception, and we do not assume any more in the future.

We are going to notify our auditor during the next audit.

Comment 7

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.