1687513 - E-Tugra: Delayed Response of Revocation Request

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[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 revocation of a certificate which commonName of "cebimde.com.tr" which is not included in the SAN of the certificate. The Revocation is completed on 18 Han 2021, But the response to reporter is not completed in 24 hours. On 19 Jan, A decision about creating this bug was taken in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1687139.
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)
   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 sent it to Security Group to investigate. The technical team did not take an action to inform reporter about the process.
   18 Jan 2021 Security Group investigate the problem for revocation and revoked. An information email was sent to reporter.
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 services are affected.
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.
   The revocation request of the mentioned certificate was completed.
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. The root cause was the history of the certificate, the certificates is queued for deletion before and could not created a new revocation requests in the system. the security personals waited the response of the technical team and management board. The second cause is our CPS describes that the revocation request is taken via forms on from web sites and directed to our ticketing systems on 7x24 hours. All responses are sent via our internal ticketing systems.
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. We are enhancing our procedures for avoiding any delay on revocation request and response procedures. The revocation procedure will be developed to explain clearer to public and internal staff.

Final Incident Report will be published from here.

Comment 1

[George [:fozzie]]

I think part of the issue here is some ambiguity in the CPS. In version 4.6 (latest at the time of writing) there is the following text in section 4.9.3. "Procedures for Revocation Request":[1]

“e-tuğra” gives certificate revocation service continuously on 7 days 24 hours basis via e-tuğra’s website and/or call center. The requests made by a declarative statement written by the certificate owner are processed within official working hours. For all type of SSL ve CSC certificates, revocation request is taken only by call center or with declarative statements.

To me, this seems to suggest to me that only the certificate owner can request revocation via these mechanisms, which is compounded by there being no links to the support ticket process or contact details for the call center.

The section then goes on to explain in detail how a certificate owner would go about authenticating and revoking a certificate, without also going into detail about how other parties would submit a certificate revocation request.

Further down the section also mentions that revocation requests can also be sent via e-mail, which seems to contradict the statement in the first paragraph of the section?

Revocation request can be done via call center, or email or support website of e-tugra or written statement.

To resolve some of the confusion here, E-Tugra could specifically mention the accepted ways to provide a certificate revocation request with details for third parties as well as the current details provided for certificate owners.

If we take a look at DigiCert's CPS for example, you'll find the contact information specifically related to sending revocation requests for third parties in section 1.5.2.1. "Revocation Reporting Contact Person".[2]

[1] - https://e-tugra.com.tr/Portals/6/Documents/E-Tugra_SUE_v4.6_EN.pdf
[2] - https://content.digicert.com/wp-content/uploads/2020/10/DigiCert-CPS-V.5.4.1.pdf

Comment 2

[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 revocation of a certificate which commonName of "cebimde.com.tr" which is not included in the SAN of the certificate. The Revocation is completed on 18 Han 2021, But the response to reporter is not completed in 24 hours. On 19 Jan, A decision about creating this bug was taken in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1687139.
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)
   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 sent it to Security Group to investigate. The technical team did not take an action to inform reporter about the process.
   18 Jan 2021 Security Group investigate the problem for revocation and revoked. An information email was sent to reporter.
   18 Jan 2021 Security Group and all related departments started an investigation the root cause of the problem.
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 services are affected.
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.
   The revocation request of the mentioned certificate was completed.
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. And there is no more revoke request similar to this case.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   One of the root causes was the history of the certificate, the certificates is queued for deletion before and could not create a new revocation requests in the system. the security personals waited the response of the technical team and management board.
   The second cause is our CPS describes that the revocation request is taken via forms on from web sites and directed to our ticketing systems on 7x24 hours. All responses are sent via our internal ticketing systems.
   The main cause is email based third party revocation request are handled manually by security personal. These emails also are transferred to our ticketing system but not marked as revocation request.
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 are implementing the following changes in our procedures and systems.

• We created a new email address and contact information for third party revocation requests, in addition to our web site forms https://helpdesk.e-tugra.com.tr/submit_ticket ). All emails send to this address will be directed to our ticketing system as revocation request. The system will force to the staff to take an action and a response for these requests in 24 hours like other revocation requests of certificate owners. The updates and tests will be completed in a week.
• We will update our CPS and all related revocation internal process documents with clear explanation. Revocation channels and revocation requesters and request methods will be explained in clear. The CPS will be published in February with other planned updates.
• Our procedures will include a response in 24 hours even required action cannot be taken due to technical or unexpected reasons in 24 hours for revocation request.
• Internal training plans for security staff was updated and the training frequency was increased for all certificate lifecycle process including revocation.

Comment 3

[Davut Tokgöz]

Update and Close Request
We created a new email address and contact information for third party revocation requests, in addition to our web site forms https://helpdesk.e-tugra.com.tr/submit_ticket). All emails send to this address is directed to our ticketing system as revocation request. The system forces the staff to take an action and a response for these requests in 24 hours like other revocation requests of certificate owners.
We updated our CPS and all related revocation internal process documents with clear explanation. Revocation channels and revocation requesters and request methods are explained in clear. A dedicated contact for revocation is placed on CPS. The CPS is approved and published with other planned updates.
Our procedures now include mandatorily a response in 24 hours whether or not the required action cannot be taken due to technical or unexpected reasons in 24 hours for revocation request. All security staff was updated with the revocation process and rules.

Comment 4

[Ben Wilson]

I will schedule this to be closed on or about Wed. 7-April-2021.