1687139 - E-Tugra: commonName not in SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[George [:fozzie]]

E-Tugra has issued a certificate with a commonName field which is not in the SAN extension https://crt.sh/?q=4772bd8e5f0a3aa21a49a9a50bdcc9c91324be724f05d8b224fee36e832fa968

On Friday January 15th at 15:04 UTC I sent an email to both [e-mail] and [e-mail] as outlined as contact emails in their CPS as I couldn't find a designated revocation contact email. As I haven't been sent a reply within 24 hours I'm just going to post it here.

Comment 1

[Davut Tokgöz]

This is a preliminary report.

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 15 Jan 2021 15:04 (UTC), we received an email from George ([e-mail]) about commonName of "cebimde.com.tr" which is not included in the SAN of the certificate. And on 16 Jan 2021 15:09 (PST), this bug is created and assigned to us on 17 Jan.
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.
   (all times are GMT)
   23 Dec 2020 12:33 The mentioned certificate was issued.
   24 Dec 2020 14:18 The problem on certificate is found and a new certificate was issued ( https://crt.sh/?q=743ce2eddb7c9389171be64ee7cf1c5458a4829c89b8c327a3830ca5686d5225 ) . The first certificate was marked for revocation.
   15 Jan 2021 18:10 An email from George was received.
   16 Jan 2021 The technical persons queried certificates on our systems system and find that it was reissued and marked for revocation. To take an action, he send it to Security Group to investigate.
   18 Jan 2021 Security Group investigate the problem for revocation and revoked
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.
   This is still under investigation.
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.
   All certificates are examined and only this certificate had this problem.
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.
   There are no more certificates were issued with the same problem.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   This is still under investigation.
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.
   This is pending completion of our investigation.

Comment 2

[George [:fozzie]]

Thank you for your preliminary report.

I see 3 separate issues here:

1. The actual issuance of a certificate with a commonName not included in the SAN extension (BR 7.1.4.2.2).
2. The failure to respond with a preliminary report within 24 hours (BR 4.9.5).
3. The failure to revoke the certificate within 5 days after detection (24 December -> 18 January) (BR 4.9.1.1).

Can E-Tugra open separate bugs for #2 and #3 and provide preliminary reports on them as well?

Comment 3

[paul.leo.steinberg]

(In reply to george from comment #2)

I see 3 separate issues here:

1. The actual issuance of a certificate with a commonName not included in the SAN extension (BR 7.1.4.2.2).

In fact, the missing incident report about this issue is a fourth issue in itself (Mozilla Root Store Policy 2.4, "CAs MUST promptly report all incidents").

Comment 4

[Davut Tokgöz]

Our Idea is that a single bug will be enough for tracking all, because all delays are trying to understand and trying to find a proper solution for fixing the original problem. But we are creating related bugs as requested.

Comment 5

[George [:fozzie]]

Normally it is better to have separate bugs to organise the separate incidents, although we can ask Ben if he would prefer it all in one bug.

Comment 6

[Ben Wilson]

I think we need three bugs. One for the underlying issue and its remediation. One for the delayed response to George. One for delayed revocations. The 4th issue (delayed provision of an incident report) can be addressed here.

Comment 7

[Davut Tokgöz]

We created a bug for the delayed response to George https://bugzilla.mozilla.org/show_bug.cgi?id=1687513 . We believe that "delayed revocation" is highly connected to the certificate history and to this bug. If Ben and George approve, we will give the final Incident Report with this bug. We continue to investigate and fixing the problem and create a final report.

Comment 8

[George [:fozzie]]

I don't quite understand how the delay in revocation can be linked specifically to this issue. As you have already said, E-Tugra reissued the certificate with the correct values after it discovered there was an issue. After the certificate was reissued then why did E-Tugra not revoke the misissued certificate within 5 days?

Comment 9

[Davut Tokgöz]

We agree with your comments. We created a new bug about "The failure to revoke a certificate" the preliminary report is posted in. https://bugzilla.mozilla.org/show_bug.cgi?id=1687608

Comment 10

[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.
   On 15 Jan 2021 15:04 (UTC), we received an email from George ([e-mail]) about commonName of "cebimde.com.tr" which is not included in the SAN of the certificate. And on 16 Jan 2021 15:09 (PST), this bug is created and assigned to us on 17 Jan.
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.
   (all times are GMT)
   23 Dec 2020 12:33 The mentioned certificate was issued.
   24 Dec 2020 14:18 The problem on certificate is found and a new certificate was issued ( https://crt.sh/?q=743ce2eddb7c9389171be64ee7cf1c5458a4829c89b8c327a3830ca5686d5225 ) . The first certificate was marked for revocation.
   15 Jan 2021 18:10 An email from George was received.
   16 Jan 2021 The technical persons queried certificates on our systems system and find that it was reissued and marked for revocation. To take an action, he send it to Security Group to investigate.
   18 Jan 2021 Security Group investigate the problem for revocation and revoked
   18 Jan 2021: We started more detailed investigation how this error occurs.
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.
   None of CA functionalities have been stooped.
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.
   All certificates are examined and only this certificate had this problem.
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.
   There are no more certificates were issued with the same problem.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   This was caused by our RA system. The certificate was prepared with marketcebimde.com.tr, cebimde.com.tr and with their subdomain with www.
   We run the similar scenario many times on our test system and could not create the same bug.
   The error was catched in certificate by our system and the certificate was not send to Subscriber. Next day it was reissued with the correct values.
   Our systems alert any error in all certificate pre issuing and post issuing. We have 3 level validation controls.
   • Pre validations: applied before certificate is issued.
   • Post validations: applied after certificate is issued.
   • Zint controls: applied after post validations as Final Control.
   This error was catched by our post validation controls and is marked an error, but not marked as mis issued. Final zlint validations was not applied for this certificate due to an error found in previous controls.
   Many certificates that are reissued s revoked after a time period and this certificate was placed in this list in our reports.
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 related certificate issue modules are revised and updated that avoids SAN and commonname conflict. After finalizing of certificate fields pre-validation controls cover that the common name field in subscriber certificates is quarantined only names from the SAN extension.
   Post-validation controls were reviewed to manage all possible errors. The system was covered. Zlint validations are being applied whether the post validations are success or failure.
   We are developing a workflow that when any error occurs in certificate issue whether it is misissue or not, will be reviewed and approved whether is approved or not by trusted personals in our systems. We will complete it on the middle of Feb. We update internal procedures with this workflow.
   With these works we will catch all mis-issue certificates when they are issued and report them to public in 24 business hours.

Comment 11

[George [:fozzie]]

Thanks for your response, is there any reason that E-Tugra performs Zlint validation after the certificate has been signed? As outlined in CA/Required_or_Recommended_Practices, zlint can check a tbsCertificate, therefore preventing a possible misissuance.

Comment 12

[Rob Stradling]

As outlined in CA/Required_or_Recommended_Practices, zlint can check a tbsCertificate

Hi george. IINM, that statement is a bit misleading. I'm not aware of any linter that can accept a tbsCertificate directly. My code (for https://crt.sh/linttbscert and for Sectigo's pre-issuance linting) puts the tbsCertificate into a "dummy" certificate (i.e., append a fake signature that passes the linters' signature syntax checks), then passes that dummy certificate to the linters.

Comment 13

[George [:fozzie]]

(In reply to Rob Stradling from comment #12)

As outlined in CA/Required_or_Recommended_Practices, zlint can check a tbsCertificate

Hi george. IINM, that statement is a bit misleading. I'm not aware of any linter that can accept a tbsCertificate directly. My code (for https://crt.sh/linttbscert and for Sectigo's pre-issuance linting) puts the tbsCertificate into a "dummy" certificate (i.e., append a fake signature that passes the linters' signature syntax checks), then passes that dummy certificate to the linters.

Thanks Rob! The way it's worded in the wiki makes it seem like zlint just omits signature checks if it's parsed a tbsCertificate but it seems like that's not the case.

I think E-Tugra should look into implementing a similar version to this if possible though.

Comment 14

[Davut Tokgöz]

We have been applying "Pre-Validation Controls" before a certificate is issued. We are also enhancing these controls to discover that all possible missue cases before it is issued. Our design covers also "Post Validations Controls" and "Zlint Controls" after issuing a certificate to catch any problem.
Your suggestion shed light on us. We discussed whether it is possible or not. We started an integration process for zlint controls before certificates are signed.

Comment 15

[Ben Wilson]

Please provide an update on your progress to implement pre-issuance and post-issuance controls.

Comment 16

[Davut Tokgöz]

Hi.
As explained before, the 2 level of validation with zlint controls after issuing certificates were implemented. As mentioned, an approval and review mechanism for all kind of errors in the certificate issues were also implemented.
We integration of zlint controls before certificates signing (to the tbsCerticate stage) are being continued with test stages and the target publishing date is middle of the March.
We will notify again when all tasks are completed.

Comment 17

[Ryan Sleevi]

We're now at the end of March with no update.

Comment 18

[Davut Tokgöz]

Update and Close Request
The related certificate issue modules were revised and updated that avoids SAN and commonname conflict. After finalizing of certificate fields pre-validation controls cover that the common name field in subscriber certificates is quarantined only names from the SAN extension.

We completed the integration of zlint controls before certificates signing (to the tbsCerticate stage) and tests are completed. The development and tests are completed and we will apply them on production at the end of this week on (3rd, April)

Post-validation controls were reviewed to manage all possible errors. The system was covered. Zlint validations were being applied whether the post validations are success or failure.

We developed a workflow that when any error occurs in certificate issue whether it is misissue or not, it is being reviewed and approved for revocation by trusted personals in our systems. We completed it at the end of February of Feb. We rebuild internal procedures ve process with this workflow.

Comment 19

[Ben Wilson]

I will close this on or about next Wed. 7-Apr-2021 unless there are other items to discuss.