1843268 - NAVER Cloud Trust Services: OV certificate issued with OU field

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Han Yong, Park]

We become aware of an OV SSL certificate with OU field issued by NAVER Secure Certification Authority 1 on 28 June 2023.
Today we have revoked the affected certificate:

• https://crt.sh/?id=9768660489&opt=ocsp

We have started investigations and a full report will be posted in the coming days.

Comment 1

[Han Yong, Park]

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 the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

On June 28th, NAVER Cloud have issued a certificate for a NAVER owned domains via NAVER internal certificate issuance system (internally, it is called "NAVER Domain Certificate Manager", hereinafter referred to as NDCM).
At UTC 2023-7-13 06:15, it was became aware of the Organization Unit (hereinafter referred to as OU) field was included in the certificate, during the security check before opening the web service which the certificate was issued.
After issuing and replacing with a new certificate, the certificate containing the OU field was revoked immediately at UTC 2023-7-13 10:22.

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.

YYYY/MM/DD - Time in UTC	Description of actions
2023-06-28 07:42	Issuance of certificates with OU field
2022-07-13 06:15	Detection of the fact that one(1) certificate with OU field was issued
2022-07-13 10:22	Revocation of the affected certificate
2022-07-13 11:39	Issuance of a preliminary incident report comment#0 and started investigating
2022-07-13 13:00	(Root cause found) When submitting a CSR with an OU field, it was confirmed that the CSR validation logic of NDCM failed to check it. It was confirmed that the x509 lint applied to the CA failed to check whether the OU field was included. (x509 pre-lint function released to CA applications in September 2022). The affected certificate's CSR was externally generated and submitted to NDCM by an applicant. Until this certificate was issued, only the CSR auto-generation function included in NDCM was used, and the OU field entry form was removed before September 1, 2022, from NDCM's CSR auto-generation. However, by this investigation, it was confirmed that there was no logic to check whether the OU field was included when validating CSRs generated externally and automatically generated by NDCM.
2022-07-13 13:30	It has been decided to stop issuing a certificate using externally generated CSRs in NDCM. We started to establish countermeasures by sharing the problems of NDCM and CA Application.
2022-07-17 02:00	(NDCM hotfix scheduled) We will deploy a validation logic for whether the OU field is included in a CSR this week.
2022-07-17 08:38	(CA improvement scheduled) We plan to add additional pre-linting based on Zlint by August.

3.Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

Upon become aware of the root cause of this misissuance, we have stopped issue an OV certificate that submitted a CSR generated externally at NDCM.
The CA application is in operation and except this misissuance case, subscriber certificates can be issued normally.

4 A summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued.

Total number of affected certificates: 1

• The only one(1) affected certificate was issued on UTC 2023-06-28 07:42

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.

Please see:
https://crt.sh/?id=9768660489

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

(Cert application system side) The affected certificate's CSR was externally generated and submitted to NDCM by an applicant. Until this certificate was issued, only the CSR auto-generation function included in NDCM was used, and the OU field entry form was removed before September 1, 2022, from NDCM's CSR auto-generation. However, by this investigation, it was confirmed that there was no logic to check whether the OU field was included when validating CSRs generated externally and automatically generated by NDCM. The CSR validation result has appeared as 'Success' on the screen, and the Validation Specialist has recognized it as normal and requested a certificate issuance.

(CA system side) It was confirmed that the x509 lint applied to the CA failed to check whether the OU field was included. The x509 lint-based pre-lint function was released to CA applications in September 2022.

(How this avoided detection until being detected) It was a first time that a certificate was issued using a CSR generated outside of NDCM, and the CSR validation logic did not check whether the OU field was included. The CA application's x509 lint-based pre-lint did not check whether the OU field was included, and it recognized it as a normal case, so it issued the certificate. In terms of certificate compliance, it was issued before the upcoming internal audit cycle arrived and was not immediately detected.

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

1. Actions to be taken in NDCM and CA applications are as follows. The schedule is rough at the moment, and we will leave follow-up comments when the action is complete.

Schedule	Target	Description of actions
By July 23, 2023	NDCM	We will deploy a validation logic for whether the OU field is included in a CSR.
By August 2023	CA	We plan to add additional pre-linting based on Zlint.

2. To reduce the detection delay of misissuances that have already occurred, a manual monitoring process using an external lint statistical tool (i.e. crt.sh) will be implemented from this week. Once the internal lint is advanced, we can consider the introduction of automated monitoring in the future.

Comment 2

[Matthew McPherrin]

Are there other pieces of data which are taken from the CSR but not validated before being included in a certificate? Perhaps other RDNs in the subject? Was this incident caused by a bug specific to the OU in CSRs, or is it one in a class of bugs?

Comment 3

[Han Yong, Park]

This bug was caused by an issue specific to OU. In NDCM, subscbribers can apply BR DV and OV certificates. Before completing an OV cert CSR submission, there is a check logic to process whether the it was generated with the DNs only included CN, C, L, S, O and OU(although OU is planned to be excluded from DNs that can be submitted in NDCM, but include this because it was possible at the time of the bug occurrence). As mentioned in paragraph one of incident report number 6, during CSR validation, the result was shown 'Success' (this CSR validation logic is same with the processing in subscriber side), we are taking measures this issue.

Comment 4

[Han Yong, Park]

The update for NDCM, as mentioned in the full report number 7, was completed at UTC 2023-07-25 19:38. We will report on the CA patch as soon as it is completed.

Comment 5

[Han Yong, Park]

Attachment: Ok

Comment 6

[Han Yong, Park]

Comment on attachment 9345949 [details]
Ok

>##

Comment 7

[Han Yong, Park]

Please disregard comments 5 and 6. I apologize for any confusion caused.

Comment 8

[Han Yong, Park]

As mentioned in the full report number 7, the addition of pre-linting based on Zlint to the CA Application was completed at UTC 2023-08-21 07:30. This measure will prevent the issuance of certificates not only in this incident case but also in other error cases handled by Zlint.

Comment 9

[Ben Wilson]

Greetings,
Is this issue fully remediated and are measures in place to prevent this type of misissuance from reoccurring?
Thanks,
Ben

Comment 10

[Han Yong, Park]

Yes, The root cause of this issue has been addressed, and measures to prevent its recurrence have been fully implemented.

Comment 11

[Ben Wilson]

I will close this on Friday, 29-Sept-2023, unless there are additional questions or issues to address.