2004733 - NAVER Cloud Trust Services: CA Certificate not published in DER Encoded Format

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Hogeun Yoo]

Preliminary Incident Report

Summary

• Incident Description:
  It was identified that the file referenced by the id-ad-caIssuers URI within the Authority Information Access (AIA) extension of an intermediate certificate is provided in PEM format rather than the DER-encoded format expected by RFC 5280 and the CA/Browser Forum Server Certificate Baseline Requirements (BR). We are reviewing whether this affects other intermediates that reference the same hosting path.

• Relevant policies:
  RFC 5280 Section 4.2.2.1 and BR Section 7.1.2.10.3

• Source of incident disclosure:
  Third-party report via Bugzilla

Comment 1

[Hogeun Yoo]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A005672

• Incident description:
  A Subordinate CA certificate contained an AIA caIssuers URL pointing to a Root CA certificate file that was published in PEM-encoded format instead of the required DER-encoded format, resulting in non-compliance with RFC 5280 Section 4.2.2.1.

• Timeline summary:

  • Non-compliance start date: 2017-08-18 (initial Root CA creation)
  • Non-compliance identified date: December 8, 2025 14:58 UTC
    (The CA acknowledged receipt of the report in Bugzilla and initiated the investigation)
  • Non-compliance end date: December 8, 2025 21:05 UTC

• Relevant policies:

  • RFC 5280 Section 4.2.2.1

• Source of incident disclosure:
  Third-party report via Bugzilla
  https://bugzilla.mozilla.org/show_bug.cgi?id=2004698

Impact

• Total number of certificates:
  N/A

• Total number of "remaining valid" certificates:
  N/A

• Affected certificate types:
  N/A

• Incident heuristic:

  • The potential impact of this incident may affect application clients that perform operations by utilizing the caIssuers information within the certificate's authorityInfoAccess extension.
  • The NAVER Global Root Certification Authority has currently issued the following Subordinate CA certificates, which are affected by this incident.

  crt.sh ID	Not Before	Not After	Subject Name
  126361	2017-08-18	2027-08-18	CN=NAVER Secure Certification Authority 1; O=NAVER BUSINESS PLATFORM Corp.; C=KR
  439300	2025-11-19	2035-11-19	CN=NAVER Secure Certification Authority 2; O=NAVER Cloud Trust Services Corp.; C=KR
  272052	2024-12-09	2038-12-09	CN=NAVER Cloud Trust Services ECC Root G1; O=NAVER Cloud Trust Services Corp.; C=KR
  272053	2024-12-09	2038-12-09	CN=NAVER Cloud Trust Services RSA Root G1; O=NAVER Cloud Trust Services Corp.; C=KR

  • Since the AIA of these Subordinate CA certificates all point to the same Root CA certificate URL, which was previously published in PEM-encoded format instead of DER, the scope of impact is limited to the Subordinate CA certificates listed above.

• Was issuance stopped in response to this incident, and why or why not?:
  No. Certificate issuance was not stopped because the issue did not affect end-entity certificates, did not result in mis-issuance, and posed no security risk to relying parties.

• Analysis:
  N/A

• Additional considerations:
  N/A

Timeline

• August 18, 2017
  The Root CA was initially created. At that time, a Root CA certificate in PEM-encoded format was published at the Root CA URL referenced by the AIA caIssuers field of subsequently issued Subordinate CA certificates.

• December 8, 2025 13:45 UTC
  The Reporter submitted an incident report to the Mozilla Bugzilla CA Certificate Compliance component
  (Bug ID: 2004698).

• December 8, 2025 14:58 UTC
  The CA acknowledged receipt of the report in Bugzilla and formally initiated an investigation.

• December 8, 2025 16:04 UTC
  The CA submitted the Preliminary Incident Report in Bugzilla and began the initial internal investigation.

• December 8, 2025 16:07 UTC
  The CA convened an internal incident response meeting and initiated analysis of the root cause and potential corrective actions.

• December 8, 2025 21:05 UTC
  The CA completed a detailed review of the affected configuration and replaced the PEM-encoded Root CA certificate published at the referenced URL with a correctly DER-encoded certificate.

• December 9, 2025 00:00 UTC
  Additional internal discussions were conducted, including a review of similar incidents disclosed in the Bugzilla CA Certificate Compliance component and an assessment of alternative root causes for comparable compliance issues.

• December 9, 2025 08:32 UTC
  The CA formally defined and approved corrective and preventive measures as organizational policy, following executive (C-level) review and approval.

Related Incidents

Bug	Date (UTC)	Description
2004732	December 8, 2025 15:59 UTC	AIA caIssuers field pointing to a PEM-encoded certificate
2004668	December 8, 2025 10:56 UTC	Root-CA certificates published in PEM-encoded format
2005762	December 12, 2025 15:19 UTC	Failure to respond to a Certificate Problem Report (CPR) within 24 hours
2005399	December 11, 2025 02:49 UTC	caIssuers returns a PEM-encoded certificate (RFC 5280 Section 4.2.2.1 violation)
2005149	December 10, 2025 08:19 UTC	CA certificate not published in DER-encoded format
2004521	December 6, 2025 06:30 UTC	CA certificate not published in DER-encoded format
2004492	December 6, 2025 23:02 UTC	CA certificate not published in DER-encoded format
1938167	December 18, 2024 17:58 UTC	CRL not published in DER-encoded format

Root Cause Analysis

Contributing Factor #1: Lack of ongoing validation of legacy Root CA publication artifacts

• Description:
  The Root CA certificate file referenced by the AIA caIssuers field of certain Subordinate CA certificates was created and published during the initial Root CA setup in August 2017. The Root CA certificate was published in PEM-encoded format. Although the applicable requirement (RFC 5280) did not change, there was no ongoing or periodic validation process to verify that externally published Root CA certificate files continued to comply with the required DER encoding format. As a result, the PEM-encoded Root CA certificate remained published at the referenced URL for an extended period.

• Timeline:
  The non-compliant Root CA certificate publication originated at the time of initial Root CA creation in August 2017 and persisted until it was identified and corrected in December 2025.

• Detection:
  The issue was detected through a third-party report submitted to the Mozilla Bugzilla CA Certificate Compliance component.

• Interaction with other factors:
  While subsequent certificate generation processes were automated to produce DER-encoded certificates, previously published legacy Root CA artifacts were not subject to revalidation or review, allowing the PEM-encoded Root CA certificate to persist.

• Root Cause Analysis methodology used:
  Process gap analysis combined with a historical review of Root CA creation and publication procedures.

Contributing Factor #2: Absence of an explicit verification control for externally published CA certificate files

• Description:
  Regardless of how CA certificates were generated at different points in time, there was no explicit procedural control requiring a human verification to confirm that externally published Root and Subordinate CA certificate files were published in the required encoding format (DER). While the current certificate generation system is designed to produce DER-encoded certificates, the absence of a mandatory verification step prior to publication meant that a legacy PEM-encoded Root CA certificate file could remain published without detection.

• Timeline:
  This lack of an explicit verification control for externally published CA certificate files existed until December 2025, when a formal verification step was introduced as part of the Root and Subordinate CA creation and publication procedures.

• Detection:
  The absence of this verification control was identified during the internal investigation following the Bugzilla report.

• Interaction with other factors:
  Reliance on certificate generation processes without a defined human verification step for externally published artifacts allowed the legacy PEM-encoded Root CA certificate file to persist undetected.

• Root Cause Analysis methodology used:
  Control effectiveness assessment and review of Root and Subordinate CA certificate creation and publication workflows.

Lessons Learned

• What went well:
  The issue was promptly acknowledged and investigated after disclosure, corrective action was implemented on the same day, and a focused scope assessment confirmed that the impact was limited to specific Subordinate CA certificates.

• What didn’t go well:
  Legacy Root CA publication artifacts created during the initial CA setup were not included in later compliance validation activities, allowing a non-compliant encoding format to persist undetected.

• Where we got lucky:
  The issue had no security impact, did not affect end-entity certificates, and did not result in TLS failures or trust validation issues for relying parties.

• Additional:
  This incident reinforced the importance of explicitly validating externally published CA artifacts, even when certificate generation itself is automated.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Replace PEM-encoded Root CA certificate with DER-encoded version	Corrective	Root Cause #1	Root CA certificate is published in DER format and successfully parsed	2025-12-08	Completed
Conduct inventory review of Root and Subordinate CA publication endpoints	Detective	Root Cause #1	No additional non-compliant publication artifacts identified	2025-12-08	Completed
Document and enforce verification of encoding format for externally published CA certificate files	Preventive	Root Cause #2	Procedure approved and applied during Root/SubCA creation	2025-12-09	Completed

Comment 2

[Dustin Hollenback (Apple)]

Hello. I noticed that this bug is Third‑Party Reported and your Related Incidents section is missing several other incidents with the same issue from last year. Since similar issues were disclosed by several other CAs last year, it’s unclear whether you are monitoring incident reports from the broader community. Public disclosures are intended to help all CA operators learn from each other’s findings.

Could you confirm whether you review other CAs’ incident reports as part of your internal processes? If so, a brief overview of how you track these reports and incorporate relevant lessons would be helpful. It would also be useful to understand how this issue was ultimately identified through a third‑party report rather than your internal monitoring.

Comment 3

[Hogeun Yoo]

(In reply to Dustin Hollenback (Apple) from comment #2)

Hello. I noticed that this bug is Third‑Party Reported and your Related Incidents section is missing several other incidents with the same issue from last year. Since similar issues were disclosed by several other CAs last year, it’s unclear whether you are monitoring incident reports from the broader community. Public disclosures are intended to help all CA operators learn from each other’s findings.

Could you confirm whether you review other CAs’ incident reports as part of your internal processes? If so, a brief overview of how you track these reports and incorporate relevant lessons would be helpful. It would also be useful to understand how this issue was ultimately identified through a third‑party report rather than your internal monitoring.

Hello Dustin,

We provide the following clarification regarding our monitoring and integration processes.

1. Process Evolution and Monitoring Our CA monitors Bugzilla and CCADB to track the evolving Web PKI landscape. In this specific case, the mapping of community findings to our internal review list involved manual verification steps, which led to the omission of the related incidents you identified. We are now transitioning this workflow to a fully automated framework.

2. Automated Integration via Bugzilla API and AI To eliminate manual dependencies, we are upgrading our infrastructure to integrate the Bugzilla API with AI-driven analysis. This system will automatically extract and categorize incident data from the broader community.

The primary objective of this upgrade is the systematic integration of these external insights into our internal automated controls. This ensures that lessons learned from the community are automatically synthesized and reflected in our monitoring and linting processes as part of our continuous improvement cycle.

3. Internal Detection and Remediation While our system maintains rigorous automated checks, this particular edge case was not previously captured by our internal monitoring, leading to its identification via a third-party report. We are treating this as a gap in our automated detection suite and are currently deploying new automated controls to address this specific scenario.

Comment 4

[incident-reporting]

This report has gone stale. If it is ready for closure, please file a Closure Report.

Comment 5

[Hogeun Yoo]

Report Closure Summary

• Incident description: A Subordinate CA certificate contained an AIA caIssuers URL pointing to a Root CA certificate file published in PEM-encoded format instead of the required DER-encoded format, resulting in non-compliance with RFC 5280.
• Incident Root Cause(s): Reliance on manual monitoring for legacy artifacts and the absence of an explicit procedural control to verify encoding formats during the publication process.
• Remediation description: The non-compliant PEM file was immediately replaced with a DER-encoded version. We also completed a full inventory audit of all publication endpoints and integrated a mandatory encoding verification step into our official Root/SubCA publication SOP.
• Commitment summary: NAVER Cloud Trust Services is actively developing an automated monitoring framework that integrates the Bugzilla API with AI-driven analysis. As part of this ongoing commitment, we are systematically reviewing historical community incident reports one-by-one to identify potential gaps and incorporate those lessons into our internal controls. This proactive analysis, combined with our evolving automated detection suite, will ensure continuous adherence to Web PKI standards.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 6

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2026-01-14.