1576133 - SECOM: Mis-issued EV Certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Yuu Hidaka]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Actual results:

We investigated and found the Mis-issued EV Certificates.
We already revoked the certificate with problem.

Here is our incident 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.

2019/8/19 10:00(JST)
Upon receiving the mail from Mr. David Cook, in which he pointed out that there are problems in our 4 certificates, we first became aware of the problem.

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/8/19 10:00(JST)
Upon receiving the mail from Mr. David Cook, in which he pointed out that there are problems in our 4 certificates, we first became aware of the problem

2019/8/20 20:40(JST)
We finished the revocation of the 3 certificates.

https://crt.sh/?id=718254259
https://crt.sh/?id=718254346
https://crt.sh/?id=766866289

2019/8/21 15:18 (JST)
We revoked the last 1 certificate, which complete the whole revocation.

https://crt.sh/?id=798162704

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.
   Beside the ones that were pointed out, we found 8 more certificate with the same problem as follows, which we already revoked:

Beside the ones that were pointed out, we found 8 more certificate with the same problem as follows, which we already revoked:

https://crt.sh/?id=718254465
https://crt.sh/?id=718254343
https://crt.sh/?id=718254253
https://crt.sh/?id=718254354
https://crt.sh/?id=718254417
https://crt.sh/?id=718254380
https://crt.sh/?id=767742958
https://crt.sh/?id=718254549

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 certificates with problem are as follows:

https://crt.sh/?id=718254259
Not Before: Sep 5 10:14:11 2018 GMT
Not After : Sep 5 14:59:59 2019 GMT
serialNumber = 101111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254346
Not Before: Sep 5 10:39:55 2018 GMT
Not After : Sep 5 14:59:59 2020 GMT
serialNumber = 11111111111111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=798162704
Not Before: Sep 19 10:20:02 2018 GMT
Not After : Sep 19 14:59:59 2019 GMT
serialNumber = 111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=766866289
Not Before: Sep 19 10:20:02 2018 GMT
Not After : Sep 19 14:59:59 2019 GMT
serialNumber = 111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254465
Not Before: Sep 5 11:32:54 2018 GMT
Not After : Sep 15 14:59:59 2019 GMT
serialNumber = 11111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254343
Not Before: Sep 5 10:08:02 2018 GMT
Not After : Dec 1 14:59:59 2018 GMT
serialNumber = 1111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254253
Not Before: Sep 5 10:28:59 2018 GMT
Not After : Dec 2 14:59:59 2018 GMT
serialNumber = 111111111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254354
Not Before: Sep 5 11:32:04 2018 GMT
Not After : Sep 15 14:59:59 2019 GMT
serialNumber = 101111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254417
Not Before: Sep 5 11:31:45 2018 GMT
Not After : Sep 15 14:59:59 2020 GMT
serialNumber = 11111111111111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254380
Not Before: Sep 5 11:32:37 2018 GMT
Not After : Sep 15 14:59:59 2019 GMT
serialNumber = 11111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=767742958
Not Before: Sep 19 12:57:16 2018 GMT
Not After : Sep 30 14:59:59 2019 GMT
serialNumber = 111111111111
Violates section 9.2.5 of the EV guidelines.

https://crt.sh/?id=718254549
Not Before: Sep 5 12:05:21 2018 GMT
Not After : Dec 1 14:59:59 2020 GMT
serialNumber = 11111111111111
Violates section 9.2.5 of the EV guidelines.

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 certificates with problem are as follows:
https://crt.sh/?id=718254259
https://crt.sh/?id=718254346
https://crt.sh/?id=798162704
https://crt.sh/?id=766866289
https://crt.sh/?id=718254465
https://crt.sh/?id=718254343
https://crt.sh/?id=718254253
https://crt.sh/?id=718254354
https://crt.sh/?id=718254417
https://crt.sh/?id=718254380
https://crt.sh/?id=767742958
https://crt.sh/?id=718254549

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

In the renovation of our CA system on Sep. 5 and 9, 2018, we happened to set the incorrect value for the serial number of the certificate issued for operation confirmation.

At that time, we issued the certificates under the conditions as follows:
・should be in our domain (such as .secomtrust.net)
・Implemented by two person in charge

As described in No. 7, when the certificates were issued, we had a lack of review perspective on the review check sheet of the certificate profile of the test certificate used for operation confirmation. (It won’t happen again in the future because the preventive measures have already been taken)

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.

All certificates that were pointed out, have been revoked (2019/8/21).
The certificate used for operation check is the certificate for our domain, and originally, we should have entered our registration number, but when the certificates were issued, our review point of view was insufficient for the review check sheet of the certificate profile of the test certificate used for operation confirmation.

At present, the procedure for confirming the operation has been reviewed, and it has been added to the review point of view that our company information is set in all items of SubjectDN including serialNumber (2019/7/8).

In addition, the review viewpoint of the procedure for operation confirmation is added so that all certificates used after operation confirmation should be revoked. (2019/7/21).

Thank you for your consideration.

Best regards,
Yuu Hidaka

Comment 1

[Ryan Sleevi]

Could you provide the full details about what your procedure for reviewing looks like? That is, the exact procedures involved in the review process, prior to and following issuance?

Comment 2

[Yuu Hidaka]

We'd like to report that this incident occurred with the certificate for operation confirmation issued when we handled emergency maintenance.
As we performed our system maintenance, we handled it by exceptional case, and previously the specific value of serialNumber was not described in the check sheet.
Currently, we perform the review as follows:
・ Confirm that the domain name is our company: sdc-demo.jp
・ SubjectDN serialNumber is our corporate registration number: 011001040781
・ SubjectDN commonName is (host name). Sdc-demo.jp [our corporate domain]
・ Other items of SubjectDN are as follows: [Fixed value]
organizationalUnitName = PfW Test Certs
businessCategory = Private Organization
jurisdictionCountryName = JP
organizationName = SECOM Trust Systems CO.,LTD.
localityName = Mitaka
stateOrProvinceName = Tokyo
countryName = JP
・ Check the above values with multiple people before issuing.
・ After issuance, confirm that the above values are set with multiple names. In addition, it expires after confirming operation.

Best regards,
Yuu Hidaka

Comment 3

[Ryan Sleevi]

Thanks!

In terms of understanding the process, I'm surprised to see manual confirmation of the commonName. Does that mean that you may not be using a 3.2.2.4 method for validating these?

I ask, because it would seem if you're using a 3.2.2.4 approved method for domain validation, you would not need to manually confirm the subjectDN or the subjectAltName.

I appreciate the description of the test certificate profile subject name. Do you also confirm other elements of the certificate profile? We've seen CAs issue test certificates with incorrect extensions, and it seems like a holistic approach is useful.

Do you incorporate linting in part of your process before issuing? That seems like it would be useful to help provide an additional control, but if and only if you keep the linting up to date.

In general, it seems like you could automate much of the multi-party confirmation here with technical controls, so that you don't have to worry about exceptional scenarios and system maintenance. Could you provide more detail about why that approach wasn't used? For example, I can understand if you're having to manually construct the certificate via a command-line interface on an HSM, for example, but it wasn't clear if that was the case.

Comment 4

[Yuu Hidaka]

We answer the question as follows:

Does that mean that you may not be using a 3.2.2.4 method for validating these?

No, it doesn't. This certificate is the one for operation confirmation, but it is issued through the process of 3.2.2.4.

Do you also confirm other elements of the certificate profile?

Yes, the items other than the SubjectDN serial number and each other items in the certificate profile are confirmed with the system as much as possible before issuing the certificate.

Do you incorporate linting in part of your process before issuing?That seems like it would be useful to help provide an additional control, but if and only if you keep the linting up to date.

Except for the SubjectDN serial number, we confirm the certificate with the system as much as possible before issuing it.

In general, it seems like you could automate much of the multi-party confirmation here with technical controls, so that you don't have to worry about exceptional scenarios and system maintenance.Could you provide more detail about why that approach wasn't used?

In the time when we constructed the system, the corporate registration number to be set as the serial number in Japan could only be confirmed with official documents, so that it could not be automated.
As EV guideline 9.2.5 shows, there are cases where serial numbers are set with date and language, so that we’d like to consider carefully to work on the complete systemization.
At present, the examination of corporate registration numbers is checked by multiple persons in charge, and make sure that the correct value is set. Regarding with this bug, we will prevent recurrence by revising our procedure manual for confirming operation as described in the previous comment.

Comment 5

[Wayne Thayer]

Yuu: my understanding is that:

• SECOM will continue to manually issue certificates from publicly-trusted roots for testing purposes
• No automated compliance controls will be applied to these issuances
• SECOM will rely on improvements to procedures documenting this process to prevent future misissuances

Is that correct? If so, then I find this solution to be very weak. Please explain again how simply "revising our procedure manual" will prevent misissuances of this nature in the future, and why the suggestion of better technical controls has been rejected?

Comment 6

[tadahiko.ito.public]

Hi Wayne

This is Tadahiko from SECOM

It was translation failure. We do automate domain validation and some others.

This is a mistake that occurred because, in Japanese, word for reply "YES" for negative questions and "NO" for positive questions are the same word. (Affirmed by two denials)
Similarly, word for reply YES for positive questions and NO for negative questions are the same word.

We will have official comment soon.

Comment 7

[Yuu Hidaka]

Wayne-san,
We'd like to confirm what you were asking with this question, so that there is no misunderstanding each other.
Could you tell us whether you were asking about serial numbers or the entire certificate profile?

All of our comments as mentioned are serial number contents.
Very sorry if we misled you to think they were mentioned on the entire certificate profile.

Please note that our current situation is as follows:

■About certificate profiles:
・ All server certificates issued by our company are examined and issued in accordance with BR.
・ We use our own system to prevent issuing the certificates with problems, and the certificates are issued after checking (by own linting tool) with the system before issuing.
A High Risk Certificate Request is also confirmed at that time.
As the measure against phishing, the character string specified by our company is checked.

■About serial numbers:
・There was no way existed to check the serial number automatically when the system was constructed.
・Currently, we are working on the systematization, but as we commented before, there are exceptions that cannot be handled by that,
which makes an issue for us.

Kind regards and have a nice weekend.

Comment 8

[Wayne Thayer]

Yuu: My question is specifically about certificates issued by SECOM for "operation confirmation" testing. I'd like to understand what sort of technical controls are enforced on the issuance of these certificates, and what, if any, additional technical controls are being planned to ensure compliance when issuing this type of certificate. For example, it is not clear to me if all of SECOM's normal controls are applied to the issuance of these test certificates, or if the validation and compliance processing is entirely manual. My question refers both to the serial number field and the entire certificate profile.

Comment 9

[Yuu Hidaka]

Regarding with the control about the certificate profile, as we previously commented, even the case of the certificate issued in the "operation confirmation" testing, is controlled by the system as same as the usual case.

However, the serial number has not yet been systematized, which is the situation that we have now.

In the past, in case of the "operation confirmation" testing when we issued to the our own domain, the process of checking for the serial number by our company was lacking at that time.

Currently , as we described in the incident report, it has been improved to perform the same check as usual, when issuing in the "operation confirmation" testing and even when it is issued to the our own domain.

Comment 10

[Wayne Thayer]

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