1582601 - E-Tugra: Invalid DER results in failure to comply with RFC 5280 - Violating string length limit

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ryan Sleevi]

RFC 5280 defines, within the ASN.1 module, the country name as being at most two characters.

id-at-countryName AttributeType ::= { id-at 6 }

X520countryName ::= PrintableString (SIZE (2))

E-Tugra has issued a certificate with an invalid, overlong country name, as demonstrated at https://crt.sh/?id=739403962&opt=ocsp,zlint,x509lint,cablint

At time of writing, this certificate is not revoked.

In Bug 1462797, Comment 8, E-Tugra reported that as of 2019-01-31, they completely rebuilt their RFC 5280 compliance controls. This certificate was issued before then, on 2018-09-12.

Comment 1

[Ryan Sleevi]

Davut: I appreciate the detail on Bug 1462797, which from the outside seems to share the same root cause, which E-Tugra has reported as remediated. However, I think it's important to understand why this certificate was not previously detected, and what steps E-Tugra is taking to examine its historical issuance against its current policies and controls, in addition to providing the normal Incident Report

Comment 2

[Davut Tokgöz]

I am investigating the miscompliance. I will provide report as soon as possible.

Comment 3

[Davut Tokgöz]

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.
   E-Tugra:
   • We were aware of the problem via BugZilla

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.
   E-Tugra:
   History of bug before reporting in Bugzilla.
   • Jan 2: Bugzilla Reported the main the problem about incompatible certificates with RFC 5280 in bug 1462797
   • Jan 3: We found the problem on certificate issue process and we immediately decided to rebuild the software to fix the problem.
   • Jan 4-31: We tested all certificates for the same problem and discovered all the certificates were issued incompatible with RFC 5280 all of them replaced and revoked. The software’s that cause incompliance are fixed.
   History of new bug.
   Sep 19th : A certificate was reported as incompatible with RFC 5280 and issued before end of Jan 2019. This certificate had to be revoked on January within the work on Jan 2019 not reported in bug 1462797. The reported certificate was revoked.
   Sep 30th. We found the reason why we could not catch the certificate in control done at January. The reason is detailed in below. We found one more additional certificate that issued on 2018 and was not catch in previous control. This certificate was also revoked immediately.

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.
   E-Tugra:
   • As of September 30th, No more certificates are found in our systems and as of Jan 31st no more certificates will be produced with these problems.

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.
   E-Tugra:
   We found 2 certificates (one is reported in bug) incompatible with RFC 5280. One has invalid length of Organization name and the other one (reported) has invalid character in Country. Min and Max issue Dates: 2018.12.12 – 2019.01.03

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.
   E-Tugra:
   An Excel spreadsheet was prepared can be fetch from https://www.e-tugra.com.tr/downloads/reports/CertificatesWithErrorReport3.xlsx

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   E-Tugra:
   The problems that cause incompliance issuing of certificates were fixed in January 2019 and reported in bug 1462797. All certificates were recontroled with our controls, zlint; and all problematic certificates were revoked in January 2019 also. During the recontrol process of all certificates we included all active certificates and take action. These two certificates issued and tried to deliver to subscribers. But the subscribers reported that they cannot install the certificates or they wanted to reissue certificates. Both certificates are reissued in a week and existing certificates status are set as unused. In recontrol process in January these certificates are not included in control list because of their status.

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.
   E-Tugra
   The certificate issue control steps on pre-issue and post-issue steps were rebuilt wholly in January 2019 and reported in bug 1462797. After Jan 2019 no certificate was issued with same problems. We continue to improvement our system to avoid this kind of issuing incompatible with requirements.

Comment 4

[Wayne Thayer]

Davut: thank you for the incident report. It explains why these certificates were not detected, but it does not explain how certificates will not be missed in the future should E-Tugra need to investigate some other form of misissuance. Please update your answer to question #7 to explain the remediation for this issue.

Comment 5

[Davut Tokgöz]

Wayne: The updated report is below.

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.
   E-Tugra:
   • We were aware of the problem via BugZilla
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.
   E-Tugra:
   History of bug before reporting in Bugzilla.
   • Jan 2: Bugzilla Reported the main the problem about incompatible certificates with RFC 5280 in bug 1462797
   • Jan 3: We found the problem on certificate issue process and we immediately decided to rebuild the software to fix the problem.
   • Jan 4-31: We tested all certificates for the same problem and discovered all the certificates were issued incompatible with RFC 5280 all of them replaced and revoked. The software’s that cause incompliance are fixed.
   History of new bug.
   Sep 19th : A certificate was reported as incompatible with RFC 5280 and issued before end of Jan 2019. This certificate had to be revoked on January within the work on Jan 2019 not reported in bug 1462797. The reported certificate was revoked.
   Sep 30th. We found the reason why we could not catch the certificate in control done at January. The reason is detailed in below. We found one more additional certificate that issued on 2018 and was not catch in previous control. This certificate was also revoked immediately.
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.
   E-Tugra:
   • As of September 30th, No more certificates are found in our systems and as of Jan 31st no more certificates will be produced with these problems.
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.
   E-Tugra:
   We found 2 certificates (one is reported in bug) incompatible with RFC 5280. One has invalid length of Organization name and the other one (reported) has invalid character in Country. Min and Max issue Dates: 2018.12.12 – 2019.01.03
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.
   E-Tugra:
   An Excel spreadsheet was prepared can be fetch from https://www.e-tugra.com.tr/downloads/reports/CertificatesWithErrorReport3.xlsx
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   E-Tugra:
   The problems that cause incompliance issuing of certificates were fixed in January 2019 and reported in bug 1462797. All certificates were recontroled with our controls, zlint; and all problematic certificates were revoked in January 2019 also. During the recontrol process of all certificates we included all active certificates and take action. These two certificates issued and tried to deliver to subscribers. But the subscribers reported that they cannot install the certificates or they wanted to reissue certificates. Both certificates are reissued in a week and existing certificates status are set as unused. In recontrol process in January these certificates are not included in control list because of their status.
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.
   E-Tugra
   The certificate issue control steps on pre-issue and post-issue steps were rebuilt wholly in January 2019 and reported in bug 1462797. After Jan 2019 no certificate was issued with same problems. To avoid missing such certificates in the future when E-Tugra need to investigate some other form of mis issuance, we added a special instructions to our internal procedure about System Control Procedures. These instructions covers in which cases, which certificates are considered with which parameters.

Comment 6

[Ryan Sleevi]

Wayne: While this fits a trend of CAs who have examined historic issuance based on database flags, rather than what was signed, I don't think we have evidence following Bug 1462797 (or at least, I haven't looked in CT and don't remember of any incidents) that the issue has repeated. It sounds like the process has been updated procedures/documentation, to make sure all certificates are examined.

Given the trend of this, it may be worthwhile to consider in a future CA communications and/or expectations document, but I'm kicking this to you for further questions.

Comment 7

[Wayne Thayer]

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