1535869 - Taiwan-CA: Invalid SAN Entries

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Hao-Chun Li posted the following incident report to the mozilla.dev.security.policy mailing list:

Taiwan-CA wants to report an incident about mississued certificates with invalid SAN.

Times below are in UTC+8

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.
   

On 2019-03-14, we received an email reporting the problematic certificate.

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.
   

2019-03-12 16:25 The certificate is issued.
2019-03-14 02:25 The incident report is received.
2019-03-14 10:25 The certificate is revoked.
2019-03-14 14:55 We have examined the issuing system and determined the cause of the problem.
2019-03-14 15:34 We have performed an search on unexpired certificates and there’s another revoked certificate with the same problem.
2019-03-14 16:00 We have fixed the bug and planned its deployment to production environment.

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 fixed the bug in SAN validation. We will arrange additional check process by reviewing on DNS names manually before the update go live.

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.
   

Number of certs: 2
First certificate issued on 2018-05-04
Last certificate issued on 2019-03-12

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=439740567
https://crt.sh/?id=1278711906

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

There is a bug in our SAN validation code that some of the DNS names are not properly validated when there are multiple SANs.

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 bug has been fixed and the update will be deployed by 2019-03-30 at the latest.

Comment 1

[Wayne Thayer]

Hao-Chun: Your answers to questions 6 and 7 are not sufficient. At a minimum, they should answer the following questions:

• How was the bug in SAN validation code introduced?
• Why was it not detected in testing?
• What has been done to ensure that no other bugs are present in the SAN validation code?
• Why will it take until 2019-03-30 to deploy the update?
• What is being done until then to ensure that no further certificates are misissued?
• Why were the misissued certificates not detected by TWCA?
• Does TWCA perform linting? If not, why not?

Comment 2

[Hao-Chun Li]

(In reply to Wayne Thayer [:wayne] from comment #1)

Hao-Chun: Your answers to questions 6 and 7 are not sufficient. At a minimum, they should answer the following questions:

• How was the bug in SAN validation code introduced?

In the SAN validation code, after a domain name is validated, subsequent names with the same base domain name are not validated properly.

• Why was it not detected in testing?

The test cases did not cover this one.
Domain names end with the same base domain name were expected to be validated only once, but the combination of a valid name followed by malformed ones was not tested.

• What has been done to ensure that no other bugs are present in the SAN validation code?

We have reviewed the code and domain name specifications to ensure proper validation are performed for each domain name included.

• Why will it take until 2019-03-30 to deploy the update?

Our system deployment process requires completing user acceptance test by system and RA operators before deployment and 2019-03-30 is the scheduled due date of the test.
The update will be deployed as soon as possible if the test is completed earlier.

• What is being done until then to ensure that no further certificates are misissued?

Before the update completes, DNS names will be manually double checked by RA operators before approved for issuance.

• Why were the misissued certificates not detected by TWCA?

We do not have post-issuance linting now so the misissued certificate was not detected.

• Does TWCA perform linting? If not, why not?

TWCA does not implement linting yet due to resource constraints before.
We originally had planned to implement linting in Q3 2019,
and at this moment, have tightened the schedule and will implement linting in Q2 2019.

Comment 3

[Wayne Thayer]

Hao-Chun: thanks you for the additional information. Please update this bug when the update has been deployed and again when linting has been implemented.

Comment 4

[Hao-Chun Li]

The update has been deployed to the production system on March 25.

Comment 5

[Hao-Chun Li]

Linting has been implemented and deployed to production system on June 27.

Comment 6

[Wayne Thayer]

It appears that remediation has been completed.