1674886 - certSIGN: misissued an OV SSL certificate with no organizationName and localityName, instead of a DV SSL as requested by client

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Gabriel PETCU]

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

Steps to reproduce:

Following a client request for a DV SSL certificate our RA operators started the issuance procedure by creating a Pre-certificate. On the selection of the DV pre-certificate profile, the first operator has selected OV pre-certificate profile and this error was not observed by the second operator and neither caught by the pre issuance technical control mechanisms. When we received the email for the misissuance of the pre-certificate we analyzed it and revoked the pre-certificate and the associated certificate.
https://crt.sh/?id=3452584367
https://crt.sh/?id=3594110579

Actual results:

This bug filing encompasses CAs managed by Certsign S.A., which includes the following Intermediate CA:
• certSIGN Enterprise CA Class 3 G2

1. How your CA first became aware of the problem, and the time and date.
   This was first reported by [e-mail] at 18:44 EEST time on Saturday, 2020-10-31 via email to our [e-mail] reporting email address. It was opened now as this Bugzilla bug.

2. A timeline of the actions your CA took in response.
   Note: Times are listed in EEST time zone
   • 31 October 2020 18:44 – Issue reported by [e-mail] as an email
   • 31 October 2020 19:41 – Internal incident created
   • 31 October 2020 20:30 – Internal investigation started
   • 31 October 2020 21:30 – Decision to revoke the certificates established and Certificate owner notified of the requirement to revoke the certificate
   • 1 November 2020 09:00 – Analysis on the improvement of the process started
   • 1 November 2020 11:23 – Certificates revoked
   • 1 November 2020 17:29 – Certificate misissued acknowledged and response sent to George [e-mail]

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.
   Our initial investigation confirmed that there was a human error and insufficient technical controls in place. There was only one pre-certificate issued with the mentioned problem and it’s associated certificate. See next.

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.
   There was only one pre-certificate and the associated certificate issued with the mentioned problem. See next.

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.
   The known impacted certificate were already provided as crt.sh link with ID 3452584367 for the pre-certificate, respective 3594110579 for the certificate.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   The RA Officer checked documents and the CSR she received from the client. When selecting the Pre-certificate profile, she selected OV instead of DV. The second RA Officer performed the cross-check verification and failed to notice the bad selection and it’s certificate The main reason is the fact that existing pre issuance technical control mechanisms didn’t caught the wrong policy OID and passed validation.

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 will mitigate this potential problem through a system update that will add support for checks on policy OID before issuance, until November 12th. Meanwhile, any SSL requests that come in will be double-checked, also by the Supervisor, preventing further misissuance.

Expected results:

The technical controls should display the error on the operator verification.

Comment 1

[George [:fozzie]]

Thanks for the incident report. What kind of pre-issuance linting does certSIGN do? It's my understanding that both x509lint and zlint identify this issue. Additionally, does certSIGN scan it's existing certificates when new rules are added to the linting software. That is, if there are any additional certificates impacted by this issue, will they be automatically detected when a rule is added to the linting software?

Comment 2

[Bogdan Patrascu]

(In reply to george from comment #1)

Thanks for the incident report. What kind of pre-issuance linting does certSIGN do? It's my understanding that both x509lint and zlint identify this issue. Additionally, does certSIGN scan it's existing certificates when new rules are added to the linting software. That is, if there are any additional certificates impacted by this issue, will they be automatically detected when a rule is added to the linting software?

Hi George,
Gabriel in on sick leave, please find below our answers.
Currently, we are using cablint and policy OID issue was not identified as error. We planned to integrate zlint for pre-issuance linting until November 12th. Also, we will update our existing procedures to include a full scan of the existing certificate when new rules will be added to zlint.
Regards,
Bogdan

Comment 3

[George [:fozzie]]

Thanks Bogdan.

Comment 4

[Bogdan Patrascu]

On November 12th, we have installed an update in production environment and we have enforced pre-issuance checks using zlint. Also, we have performed a full scan of the existing certificates and no other issues were identified.

Comment 5

[Ryan Sleevi]

I'm not sure why this was resolved as invalid.

Comment 6

[Gabriel PETCU]

Sorry, my mistake. I accidentally marked it as INVALID.

Comment 7

[Ryan Sleevi]

Gabriel: CAs should not, in any circumstance, close bugs themselves. This is hopefully a misunderstanding, but can easily be interpreted as a CA attempting to dismiss bugs without properly addressing them. The bug will only be closed by a Mozilla representative when the community is satisfied with the response, and until then, CAs are expected to provide weekly updates. This is detailed at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed

Comment 8

[Gabriel PETCU]

It was not clear for me if I was supposed to update the status to RESOLVED, but now it is clear, thank you Ryan.
I was confused by the Bugzilla status workflow, where the developer role change it to RESOLVED and the QA role change it to VERIFIED or REOPENED. Waiting now for the proper check from the assigned roles.
Thank you again for clarifying it.

Comment 9

[Gabriel PETCU]

For info: the remediation steps have been completed since November 2020.

Comment 10

[Ben Wilson]

Unless there is anything else to discuss, I intend to close this bug on next Wednesday, 7-Apr-2021.