Chunghwa Telecom: CA Certificates Published in PEM format
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: tmkuo, Assigned: tmkuo)
References
Details
(Whiteboard: [ca-compliance] [policy-failure])
Preliminary Incident Report
Summary
- Incident description: One Chunghwa Telecom SubCA certificate file referenced in the CA Issuers URI (AIA) of issued certificates were being served in PEM format, not in DER format required by RFC 5280.
- Relevant policies: RFC 5280 4.2.2.1
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
- Source of incident disclosure: Third Party Reported.
The hosted CA certificate files have been updated to the DER format, and a full investigation is in progress. A detailed incident report will follow.
|
||
Updated•2 months ago
|
|
Assignee | |
Comment 1•1 month ago
|
||
Full Incident Report
Summary
- CA Owner CCADB unique ID: A006506
- Incident description: The GTLSCA certificate file referenced in the CA Issuers URI (AIA) of issued certificates was being served in PEM format, not in DER format required by RFC 5280. The affected URI was http://gtlsca.nat.gov.tw/Certs/GTLSCA.crt. The potential impact of this incident may affect all application systems that rely on the CA Issuer information in the authorityInfoAccess field of the certificate to complete validation or obtain the parent certificate during operation. If this information is abnormal, missing, or cannot be properly parsed, the related applications may experience failures or abnormal behavior.
- Timeline summary:
- Non-compliance start date: 2019-07-19
- Non-compliance identified date: 2025-12-10
- Non-compliance end date: 2025-12-10
- Relevant policies: RFC 5280 Section 4.2.2.1
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
- Source of incident disclosure: Third Party Reported.
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 all application systems that rely on the CA Issuer information in the authorityInfoAccess field of the certificate to complete validation or obtain the parent certificate during operation.
- Was issuance stopped in response to this incident, and why or why not?: As there were no certificates misissued, issuance was not stopped. However, this CA has already stopped issuing TLS certificates in early March 2025.
- Analysis:
- Additional considerations:
Timeline
All times are UTC+8.
2025-12-09
- 22:07: Received a third-party notification indicating an abnormal encoding format in the CA certificate.
2025-12-10
- 08:46 CHT became aware of the incident.
- 09:10 CHT holds a preliminary incident discussion meeting and identifies it violated the requirements of RFC 5280 4.2.2.1.
- 09:20 Initiate preliminary internal review and check operations.
- 10:20 Verified and confirmed the scope of impact was limited to the CA certificate format referenced in the TLS certificate AIA.
- 11:04 Informed the incident investigation committee of the current state of the incident and its scope of impact.
- 11:35 Submit a file revision change request.
- 11:50 Completed file replacement and confirmed expected results.
- 15:30 Completed inspection of all CA files; no other encoding errors were found.
Related Incidents
| Bug | Date | Description |
|---|---|---|
| 2005399 | 2025-12-10 | DV OCA caIssuers Returns PEM Encoded Certificate. |
| 2005149 | 2025-12-10 | CA Certificate not published in DER Encoded Format. |
| 2004845 | 2025-12-08 | CA Certificates Published in PEM format. |
| 2004733 | 2025-12-08 | CA Certificate not published in DER Encoded Format. |
| 2004732 | 2025-12-08 | AIA CA issuer field pointing to PEM encoded cert. |
| 2004668 | 2025-12-08 | Root-CA certificates published in PEM encoded format. |
| 2004699 | 2025-12-08 | CA in AIA in PEM format. |
| 2004521 | 2025-12-05 | CA Certificate not published in DER Encoded Format. |
| 2004492 | 2025-12-05 | CA Certificate not published in DER Encoded Format. |
| 1938167 | 2024-12-18 | CRL not published in DER Encoded Format. |
| 1914893 | 2024-08-26 | CRL not DER-encoded. |
| 1914466 | 2024-08-22 | CA Certificates not published in DER Encoded Format. |
| 1884461 | 2024-03-08 | CA Certificates not published in DER Encoded Format. |
Root Cause Analysis
Contributing Factor #1: Lack of a clear process for file release and format verification.
- Description: In the CA certificate issuance process, although the current operations already cover major steps such as issuance and configuration, there is no clear review mechanism for the CA Issuer URI in the certificate’s AIA field, which should comply with RFC 5280. This issue was not identified during file release. Moving forward, the related processes will be re-examined to ensure more comprehensive consideration of all relevant aspects.
- Timeline: The problem has existed all along.
- Detection: Notified by a third party.
- Interaction with other factors: Due to the elapsed time, it is challenging to identify additional root causes of this bug. The file placement procedure currently does not include checks for encoding format, and the existing workflow has yet to incorporate related format requirements into routine reviews. This design characteristic makes it difficult to promptly identify encoding discrepancies during the release stage. When these factors coexist, they may result in published files not fully complying with the format requirements specified in RFC 5280, constituting one of the causes of this incident. Furthermore, the absence of encoding format checks in the process makes such issues harder to detect early in daily operations, thereby increasing potential risk.
Contributing Factor #2: The verification process does not include a comprehensive set of checks.
- Description: Existing validation procedures primarily address certificate format and structural integrity, yet omit verification of AIA field links, thereby failing to achieve comprehensive certificate validation.
- Timeline: The problem has existed all along.
- Detection: Following this incident, a reassessment of the existing certificate workflow revealed that the verification procedures lacked coverage for AIA field link validation.
- Interaction with other factors: The current verification process follows existing workflows and operational practices. Given the configuration of checklist items and their coordination with related steps, checks on AIA field links were not included as a verification focus, leaving the overall certificate validation scope in need of enhancement. Moving forward, automated checking tools will be developed to provide additional support.
Lessons Learned
- What went well: The response procedure was promptly activated upon receipt of the notification, ensuring that incident handling proceeded without any delay.
- What didn’t go well: The certificate placement process is currently manual, creating potential human error risks and undermining the credibility of operational outcomes. To strengthen reliability, automated validation tools will be developed and integrated into the workflow.
- Where we got lucky: N/A
- Additional: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Fix the known files with encoding errors | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CA certificate download locations | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CRL download locations. | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Implement an automated mechanism to verify AIA field link integrity | Prevent | Root Cause # 2 | Revise and enhance the process | 2026-01-30 | Ongoing |
| Incorporate an automatic certificate file encoding verification step into the current operational workflow | Prevent | Root Cause # 1 | Revise and enhance the process | 2026-01-30 | Ongoing |
Appendix
Your timeline summary contains an earlier date (2019-07-19) that does not appear in your detailed timeline.
|
||
Comment 3•1 month ago
|
||
Hello. I noticed that this bug is Third‑Party Reported. 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.
|
|
Assignee | |
Comment 4•1 month ago
|
||
(In reply to Malcolm D from comment #2)
Your timeline summary contains an earlier date (2019-07-19) that does not appear in your detailed timeline.
Thank you for pointing out the inconsistency in the timeline. I will update our Full Incident Report.
|
|
Assignee | |
Comment 5•1 month ago
|
||
(In reply to Dustin Hollenback (Apple) from comment #3)
Hello. I noticed that this bug is Third‑Party Reported. 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.
Thank you for your valuable comment.
We periodically monitor and review incident reports disclosed by other CAs, and leverage these reports as references for internal risk assessments and process improvements. Currently, this activity is primarily conducted manually by designated personnel who track and compile updates on a regular basis and started around early 2025. We are evaluating the implementation of an automated collection mechanism to strengthen the focus on tracking topics in community discussions.
Similar incidents previously disclosed within the community have primarily served as references for overall compliance risk (not all, but data collection and review have been underway by designated personnel since early 2025). This incident underscores the need to strengthen our checks at the certificate publication level. Relevant findings are incorporated into updates to our internal checklists and operational requirements during review processes and are tracked as part of routine improvement initiatives.
In this case, the incident was identified through a third-party notification because our existing internal monitoring and verification mechanisms primarily focus on compliance checks related to certificate content and issuance processes. The non-compliance occurred at the certificate publication level—specifically, the encoding format of the CA certificate file referenced by the AIA (caIssuers) URL. This aspect was not explicitly included in our original monitoring and validation scope, which prevented timely detection through internal mechanisms.
This incident has highlighted a critical blind spot. We have integrated the lessons learned into subsequent improvements and preventive measures, including expanding the scope of checks to cover AIA link availability and downloadable content format, as well as enhancing systematic tracking and review of community CA incident reports to facilitate earlier identification and prevention of similar issues.
|
|
Assignee | |
Comment 6•1 month ago
|
||
Updated
Full Incident Report
Summary
- CA Owner CCADB unique ID: A006506
- Incident description: The GTLSCA certificate file referenced in the CA Issuers URI (AIA) of issued certificates was being served in PEM format, not in DER format required by RFC 5280. The affected URI was http://gtlsca.nat.gov.tw/Certs/GTLSCA.crt. The potential impact of this incident may affect all application systems that rely on the CA Issuer information in the authorityInfoAccess field of the certificate to complete validation or obtain the parent certificate during operation. If this information is abnormal, missing, or cannot be properly parsed, the related applications may experience failures or abnormal behavior.
- Timeline summary:
- Non-compliance start date: 2019-07-19
- Non-compliance identified date: 2025-12-10
- Non-compliance end date: 2025-12-10
- Relevant policies: RFC 5280 Section 4.2.2.1
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
- Source of incident disclosure: Third Party Reported.
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 all application systems that rely on the CA Issuer information in the authorityInfoAccess field of the certificate to complete validation or obtain the parent certificate during operation.
- Was issuance stopped in response to this incident, and why or why not?: As there were no certificates misissued, issuance was not stopped. However, this CA has already stopped issuing TLS certificates in early March 2025.
- Analysis:
- Additional considerations:
Timeline
All times are UTC+8.
2019-07-19
- The SubCA certificate was issued on this date. [start of the non-compliance]
2025-12-09
- 22:07: Received a third-party notification indicating an abnormal encoding format in the CA certificate.
2025-12-10
- 08:46 CHT became aware of the incident. [Identify of the non-compliance]
- 09:10 CHT holds a preliminary incident discussion meeting and identifies it violated the requirements of RFC 5280 4.2.2.1.
- 09:20 Initiate preliminary internal review and check operations.
- 10:20 Verified and confirmed the scope of impact was limited to the CA certificate format referenced in the TLS certificate AIA.
- 11:04 Informed the incident investigation committee of the current state of the incident and its scope of impact.
- 11:35 Submit a file revision change request.
- 11:50 Completed file replacement and confirmed expected results. [end of the non-compliance]
- 15:30 Completed inspection of all CA files; no other encoding errors were found.
Related Incidents
| Bug | Date | Description |
|---|---|---|
| 2005399 | 2025-12-10 | DV OCA caIssuers Returns PEM Encoded Certificate. |
| 2005149 | 2025-12-10 | CA Certificate not published in DER Encoded Format. |
| 2004845 | 2025-12-08 | CA Certificates Published in PEM format. |
| 2004733 | 2025-12-08 | CA Certificate not published in DER Encoded Format. |
| 2004732 | 2025-12-08 | AIA CA issuer field pointing to PEM encoded cert. |
| 2004668 | 2025-12-08 | Root-CA certificates published in PEM encoded format. |
| 2004699 | 2025-12-08 | CA in AIA in PEM format. |
| 2004521 | 2025-12-05 | CA Certificate not published in DER Encoded Format. |
| 2004492 | 2025-12-05 | CA Certificate not published in DER Encoded Format. |
| 1938167 | 2024-12-18 | CRL not published in DER Encoded Format. |
| 1914893 | 2024-08-26 | CRL not DER-encoded. |
| 1914466 | 2024-08-22 | CA Certificates not published in DER Encoded Format. |
| 1884461 | 2024-03-08 | CA Certificates not published in DER Encoded Format. |
Root Cause Analysis
Contributing Factor #1: Lack of a clear process for file release and format verification.
- Description: In the CA certificate issuance process, although the current operations already cover major steps such as issuance and configuration, there is no clear review mechanism for the CA Issuer URI in the certificate’s AIA field, which should comply with RFC 5280. This issue was not identified during file release. Moving forward, the related processes will be re-examined to ensure more comprehensive consideration of all relevant aspects.
- Timeline: The problem has existed all along.
- Detection: Notified by a third party.
- Interaction with other factors: Due to the elapsed time, it is challenging to identify additional root causes of this bug. The file placement procedure currently does not include checks for encoding format, and the existing workflow has yet to incorporate related format requirements into routine reviews. This design characteristic makes it difficult to promptly identify encoding discrepancies during the release stage. When these factors coexist, they may result in published files not fully complying with the format requirements specified in RFC 5280, constituting one of the causes of this incident. Furthermore, the absence of encoding format checks in the process makes such issues harder to detect early in daily operations, thereby increasing potential risk.
Contributing Factor #2: The verification process does not include a comprehensive set of checks.
- Description: Existing validation procedures primarily address certificate format and structural integrity, yet omit verification of AIA field links, thereby failing to achieve comprehensive certificate validation. Because our existing internal monitoring and verification mechanisms primarily focus on compliance checks related to certificate content and issuance processes. The non-compliance occurred at the certificate publication level—specifically, the encoding format of the CA certificate file referenced by the AIA (caIssuers) URL.
- Timeline: The problem has existed all along.
- Detection: Following this incident, a reassessment of the existing certificate workflow revealed that the verification procedures lacked coverage for AIA field link validation.
- Interaction with other factors: The current verification process follows existing workflows and operational practices. Given the configuration of checklist items and their coordination with related steps, checks on AIA field links were not included as a verification focus, leaving the overall certificate validation scope in need of enhancement. Moving forward, automated checking tools will be developed to provide additional support.
Lessons Learned
- What went well: The response procedure was promptly activated upon receipt of the notification, ensuring that incident handling proceeded without any delay.
- What didn’t go well: The certificate placement process is currently manual, creating potential human error risks and undermining the credibility of operational outcomes. To strengthen reliability, automated validation tools will be developed and integrated into the workflow.
- Where we got lucky: N/A
- Additional: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Fix the known files with encoding errors | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CA certificate download locations | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CRL download locations. | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Implement an automated mechanism to verify AIA field link integrity | Prevent | Root Cause # 2 | Revise and enhance the process | 2025-01-30 | Ongoing |
| Incorporate an automatic certificate file encoding verification step into the current operational workflow | Prevent | Root Cause # 1 | Revise and enhance the process | 2025-01-30 | Ongoing |
Appendix
|
||
Comment 7•1 month ago
|
||
#1 I am looking on your reports and I am having many serious concerns for the trust. You are saying that your staff is not having the "professional training" for the 24-hour response. This is making me for to wonder: How is it being possible that a CA in the Mozilla root store is not knowing the most basic rule of the CPR response? Is there being a person who is responsible for the compliance, or is the mailbox just being watched by the people who are not knowing the rules?
#2 In the history of your bugs, for example the Bug 1947034 and the Bug 1946414, you are always for to say that the "leave of absence" or the "reassignment" of one person is the reason for the failure. I must ask: Is CHT a professional organization or is it being a one-person-show? Why is there no redundancy for the compliance? If the person is to get sick, does the whole CA stop following the rules?
#3 Regarding the PEM encoding in Bug 2005567. This is a very simple technical thing. RFC 5280 is very clear. Why is your linting not catching this?
#4 Is there a reason why it is the community who is finding your bugs? Why is your internal audit not for to find that the certificates are PEM or that the EKU is wrong? Why did you not find this sooner since other bugs for other CAs were opened many days earlier, like Bug 2004699?
#5 I request that you provide the specific audit workpapers or statements of your auditor. It must be explained how this URI was verified during the audit cycles of 2023, 2024, and 2025. If no verification did happen, please explain why these audits shall be seen as valid representations of your compliance or why this auditor should be considered competent for such evaluation of public trust.
|
|
Assignee | |
Comment 8•1 month ago
|
||
(In reply to Dean F. Reed from comment #7)
#1 I am looking on your reports and I am having many serious concerns for the trust. You are saying that your staff is not having the "professional training" for the 24-hour response. This is making me for to wonder: How is it being possible that a CA in the Mozilla root store is not knowing the most basic rule of the CPR response? Is there being a person who is responsible for the compliance, or is the mailbox just being watched by the people who are not knowing the rules?
#2 In the history of your bugs, for example the Bug 1947034 and the Bug 1946414, you are always for to say that the "leave of absence" or the "reassignment" of one person is the reason for the failure. I must ask: Is CHT a professional organization or is it being a one-person-show? Why is there no redundancy for the compliance? If the person is to get sick, does the whole CA stop following the rules?
Thank you for your feedback and concern. I believe your first two questions were about Bug 2005762, but regardless, I will respond to your inquiry here. We understand that these issues reflect expectations around CA governance, compliance responsibilities, and public trust, rather than being limited to a single technical incident.
In terms of incident response and compliance operations, our CA does have established notification and handling procedures, overseen by clearly defined compliance roles. These responsibilities include managing the email for CPR, triaging and escalating issues, and ensuring backup and escalation mechanisms are in place. However, upon review, we found that the actual execution and coverage of these CPR-related processes still have room for improvement. As stated in Factor 2 of Bug 2005762, the issues highlighted the deputy were not familiar with the processes. We regard this incident as a lesson learned and have adjustments at the policy level and workflows.
Regarding concerns about personnel arrangements and backup, we agree that compliance and incident handling should not rely on any single individual. We are strengthening responsibility allocation, coverage, and cross-checking mechanisms through institutionalized measures. The related processes also include internal communication of incident response requirements and regular reviews, thereby providing more stable support for the CA’s ongoing compliance operations and mitigating risks caused by single points of dependency.
#3 Regarding the PEM encoding in Bug 2005567. This is a very simple technical thing. RFC 5280 is very clear. Why is your linting not catching this?
Regarding the fact that this incident was not immediately detected by existing inspection mechanisms, it is important to clarify that current automated and verification processes primarily focus on the core structure and field compliance of certificate content. This incident involves configuration aspects related to certificate publication and associated artifacts, such as the content referenced by the AIA (caIssuers) and its encoding format, which were previously not fully included in the scope of linting checks. This gap has been identified as a key area for improvement: we will evaluate and plan to incorporate checks for AIA link availability, format validation of retrieved content (DER), and parseability verification into automated periodic inspection and issuance workflows to reduce the likelihood of similar situations occurring again.
#4 Is there a reason why it is the community who is finding your bugs? Why is your internal audit not for to find that the certificates are PEM or that the EKU is wrong? Why did you not find this sooner since other bugs for other CAs were opened many days earlier, like Bug 2004699?
We understand the community’s concern about incidents being primarily disclosed by third parties. While we do monitor incident reports from other CAs within the community, our previous internal checks did not fully cover risks at the publication layer, which resulted in reliance on third-party reporting in this case. Furthermore, our current mechanism for collecting community issues has not systematically triggered proactive notifications for similar risks, indicating that our internal review and audit processes still have room to strengthen both scope and depth. This incident has been incorporated into our internal improvement plan as a foundation for expanding monitoring coverage and enhancing internal detection capabilities, thereby reducing future dependence on external disclosures.
#5 I request that you provide the specific audit workpapers or statements of your auditor. It must be explained how this URI was verified during the audit cycles of 2023, 2024, and 2025. If no verification did happen, please explain why these audits shall be seen as valid representations of your compliance or why this auditor should be considered competent for such evaluation of public trust.
Regarding this request, due to the confidentiality of audit procedures and contractual restrictions, we are unable to disclose specific audit workpapers or statements of our auditor. If our auditor provides any additional clarifications, I will update the response to this question accordingly.
|
|
Assignee | |
Comment 9•1 month ago
|
||
Chunghwa Telecom is monitoring this bug for comments and questions. We have no new information at the moment.
|
|
Assignee | |
Comment 10•1 month ago
|
||
Chunghwa Telecom is monitoring this bug for comments and questions. We have no new information at the moment.
|
|
Assignee | |
Comment 11•23 days ago
|
||
Chunghwa Telecom is monitoring this bug for comments and questions. We have no new information at the moment.
|
|
Assignee | |
Comment 12•18 days ago
|
||
Action Items Update
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Fix the known files with encoding errors | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CA certificate download locations | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CRL download locations. | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Implement an automated mechanism to verify AIA field link integrity | Prevent | Root Cause # 2 | Revise and enhance the process | 2025-01-27 | Completed |
| Incorporate an automatic certificate file encoding verification step into the current operational workflow | Prevent | Root Cause # 1 | Revise and enhance the process | 2025-01-27 | Completed |
|
|
Assignee | |
Comment 13•18 days ago
|
||
Make a date correction.
Action Items Update
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Fix the known files with encoding errors | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CA certificate download locations | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Perform manual verification of file encoding accuracy across all CRL download locations. | Mitigate | Root Cause # 1 | Manually download and check files | 2025-12-10 | Completed |
| Implement an automated mechanism to verify AIA field link integrity | Prevent | Root Cause # 2 | Revise and enhance the process | 2026-01-27 | Completed |
| Incorporate an automatic certificate file encoding verification step into the current operational workflow | Prevent | Root Cause # 1 | Revise and enhance the process | 2026-01-27 | Completed |
|
|
Assignee | |
Comment 14•18 days ago
|
||
Report Closure Summary
- Incident description: The GTLSCA, an ICA under Chunghwa Telecom, certificate file referenced in the CA Issuers URI (AIA) of issued certificates was being served in PEM format, not in DER format required by RFC 5280.
- Incident Root Cause(s):
(a)Lack of a clear process for file release and format verification.
(b)The verification process does not include a comprehensive set of checks. - Remediation description:
(a)Automated AIA link integrity & content verification: Implemented an automated mechanism in the compliance pipeline that fetches the AIA (caIssuers) URL, validates HTTP reachability, and parses/validates that the returned object is a DER‑encoded required by RFC 5280 certificate; failures are blocked and escalated per SOP. (Completed and documented.)
(b)Mandatory encoding verification in publication workflow: Added a required encoding check to the CA certificate publication/re‑publication checklist to ensure only DER is served for AIA targets prior to go‑live; publication cannot proceed until this check passes. (Completed and documented.)
(c)SOP & training updates: Updated internal SOPs to include the above controls and briefed CA operations and compliance staff; the AIA verification step and acceptance criteria are now part of onboarding and periodic refresher training. (Completed.)
(d)Monitoring of ecosystem incidents: Formalized a practice to periodically review public Web PKI incidents (e.g., similar PEM/DER AIA issues at other CAs) and translate them into concrete internal checklist items to prevent class‑repeats. (Practice documented and in effect.) - Commitment summary: All Action Items disclosed for Bug 2005567 have been completed. The encoding non‑compliance was remediated on 2025‑12‑10, and the automated AIA integrity/DER checks and publication‑gating controls are live and enforced. There are no remaining open deliverables for this incident. Chunghwa Telecom 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 15•18 days ago
|
||
This is a final call for comments or questions on this Incident Report.
Otherwise, it will be closed on approximately 2026-02-03.
|
|
||
Updated•11 days ago
|
Description
•