TunTrust: SSL OV mis-issuance against CP/CPS (Email attribute)
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: pki, Assigned: pki)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Attachments
(1 file)
|
1.34 KB,
text/csv
|
Details |
Summary
- Incident description:
As part of the self audit process for OV SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Distinguished Name (DN) of this certificate includes the “Email” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
The self-audit covers all SSL certificates that we issue and is not limited to a sample. It is conducted on a quarterly basis as stated in the CP/CPS.
The affected certificate was issued on May 27th, 2025, and was promptly revoked on August 6th, 2025, the same day the issue was detected.
After performing the necessary checks in order to determine whether any other certificates have the same issue, we confirmed that there are no other occurrences of this non-compliance since we started issuance with this CA hierarchy.
We will follow up with a full incident report.
-
Relevant policies:
-Self audit : section 8.7 of CA/B Forum TLS BRs v2.1.6 and section 8.7 of our CP/CPS version 06
-Subscriber Certificate profile: Section 7.1.2.7.4 and Appendix B of our CP/CPS version 06 . -
Source of incident disclosure:
Self-reported.
|
||
Updated•5 months ago
|
This bug is worse than the title indicates. Although the certificate is not listed, there are two possibilities. First, that emailAddress was included without the corresponding rfc822 name, which violates section 4.1.2.6 of RFC5280. The second is that rfc822 and emailAddress were included which violates section 7.1.2.7.12 of the CAB Forum BRs. In either case, it means that TunTrust was not using a good linter on its certificates. Therefore, I believe: 1) This is more than a violation of TunTrust's CPS and 2) TunTrust has a second or related incident related to the adequacy of its linter.
|
||
Comment 2•5 months ago
|
||
We've evaluated TunTrust's corpus and found only one affected certificate.
https://crt.sh/?id=18652895741&opt=pkimetal
We encourage TunTrust to address the points made in comment 1 in their full report.
|
Assignee | |
Comment 3•5 months ago
|
||
Full Incident Report
Summary
-
CA Owner CCADB unique ID: A000785
-
Incident description:
-
As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
-
The affected certificate was issued on May 27th, 2025, and was promptly revoked on August 6th, 2025, the same day the issue was detected.
-
The self-audit covers all SSL certificates that we issue and is not limited to a sample. It is conducted on a quarterly basis as stated in the CP/CPS.
-
After performing the necessary checks in order to determine whether any other certificates have the same issue, we confirmed that there are no other occurrences of this non-compliance since we started issuance with this CA hierarchy.
-
We use the zlint v3.6.6 and cablint v1.8.0 tools in the issuance process. After further checks, only the cablint generated an INFO level log entry for this certificate:
cablint INFO Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
zlint WARNING Subscriber Certificate: commonName is NOT RECOMMENDED.Our linting validator is configured to abort the issuance process only when an ERROR-level finding is reported.
-
The client submitted a CSR containing the emailAddress attribute and did not comply with the expected syntax:
-
The CSR content is manually reviewed by a validation specialist prior to issuance. While similar issues have been flagged successfully in the past, the control failed in this instance, as the additional attribute was not identified by the reviewer.
-
In addition, the system performs an automated check by comparing the CSR against a pre-configured certificate profile within the CA application. However, in this profile, the emailAddress attribute was marked as optional. This configuration was initially established in 2019 when the CA hierarchy was created. All profile changes are documented, logged, and monitored. Based on this, it was concluded that the configuration of the emailAddress attribute as optional originated from the initial profile setup.
-
-
No prior mis-issuance incidents have been recorded for this CA hierarchy. Previous incidents reports related to this hierarchy in Bugzilla concerned CRL and the OCSP responder availability, rather than certificate content or compliance issues.
-
This issue impacted only a single certificate, which was promptly revoked on the same day (August 6th, 2025).
-
-
Timeline summary:
- Non-compliance start date: May 27th 2025
- Non-compliance identified date: August 6th 2025
- Non-compliance end date: August 6th 2025
-
Relevant policies:
- Self audit : section 8.7 in CA/B Forum TLS BRs v2.1.6 and section 8.7 of our CP/CPS v06,
- Subscriber Certificate profile: Section 7.1.2.7.4 and Appendix B of CP/CPS v06.
-
Source of incident disclosure:
Self-reported.
Impact
- Total number of certificates: 01
- Total number of "remaining valid" certificates: 0
- Affected certificate types: This incident affects an OV SSL certificate.
- Incident heuristic: The link to the affected certificate on crt.sh : https://crt.sh/?id=18652895741
- Was issuance stopped in response to this incident, and why or why not?: Certificate issuance was stopped for certificates that are not issued through the automation process and it will resume when Action item #1 is put in place.
- Analysis: N/A
- Additional considerations: N/A
Timeline
2025- 05-27 11:59 UTC : Certificate was issued.
2025- 08-06 07:47 UTC : Internal Auditor detects the issue and issuance is ceased for certificates that are not issued through the automation process.
2025- 08-06 08:37 UTC : The scope and impact of the incident were concluded.
2025- 08-06 11:17 UTC : The affected certificate was revoked.
Related Incidents
N/A
Root Cause Analysis
Contributing Factor #: 1 - Insufficient checks after changes
- Description:
The emailAddress attribute was configured as optional in the subscriber certificate profile when the CA hierarchy was created. At that time, SSL certificate issuance was governed by version 1.6.5 of the CA/B Forum TLS Baseline Requirements (April 2019). According to section 7.1.4.2.2(j):
Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.
Based on this provision, the inclusion of the emailAddress attribute was considered acceptable, and it was marked as optional in the system’s certificate profile by the PKI administrators. However, the approved profile documented in the CP/CPS did not include this attribute.
During validation and self-audit processes, both validation specialists and internal auditors reference only the approved CP/CPS profile (and other internal approved documents) when reviewing certificates / certificate requests.
All changes to certificate profiles are subject to a formal change management process, and the monitoring system automatically reports any modifications with a detailed description.
As a result, manual checks during change control focused only on modifications, not on the full profile. The administrator relied on the assumption that the original, approved configuration remained valid unless formally changed, trusting that any unauthorized change would trigger an alert.
-
Timeline: Since the creation of the CA hierarchy.
-
Detection:
This limitation in the change-control step was not previously identified, as no unauthorized changes had occurred that would have triggered an alert. -
Interaction with other factors: N/A
Contributing Factor #: 2 Insufficient checks after issuance
-
Description:
After certificate issuance, there is no formal step to verify that the certificate content aligns with the subscriber profile defined in the CP/CPS. -
Timeline: The validation specialists team relies on pre-issuance checks and system validators to detect non-compliance. As a result, post-issuance content review is typically overlooked.
-
Detection: No other mis-issuance incidents have occurred since the creation of this CA hierarchy. As a result, the absence of post-issuance checks had not been identified as a weakness prior to this incident.
-
Interaction with other factors: Had post-issuance checks been in place, the issue could have been detected and the certificate revoked immediately after issuance, even if pre-issuance controls had failed.
Lessons Learned
-
What went well:
- The self-audit process successfully identified the non-compliance and triggered timely internal communication.
- The affected certificate was revoked within 24 hours of detection.
-
What didn’t go well:
- The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight.
- Although the validation process involves two validation specialists, neither identified the presence of the emailAddress attribute in this particular request.
-
Where we got lucky: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Update the subscriber certificate profile to omit the emailAddress attribute | Mitigate | Root Cause # 1 | Conduct a test of the certificate issuance process using a CSR that includes the emailAddress attribute, to verify whether the system aborts issuance in such cases. | 2025-08-12 | Ongoing |
| Update the certificate profile management procedure to check all the certificate profile in the change control step | Prevent | Root Cause # 1 | Certificate profile matches CP/CPS certificate profile | 2025-08-15 | Ongoing |
| Update the validation procedure to formally check the content of the certificate (post-issuance) | Detect | Root Cause # 2 | All certificates are checked upon issuance | 2025-08-15 | Ongoing |
| Add the pkimetal linting tool in the issuance process | Detect | Root Cause # 1 | The linting configuration should flag non-compliance as an ERROR, not just a WARNING or INFO | 2025-09-08 | Ongoing |
| Include the lesson learnt from this incident in the annual training of trusted roles | Prevent | Root Cause # 1&2 | High scores in evaluation tests of participants | 2025-08-29 | Ongoing |
Appendix
Uploaded CSV file
|
|
Assignee | |
Comment 4•5 months ago
|
||
|
|
||
Comment 5•5 months ago
|
||
Thank you for the full report in Comment 4.
(Q1) In the Impact Section it’s stated: “Certificate issuance was stopped for certificates that are not issued through the automation process and it will resume when Action item #1 is put in place.” Could you describe the automation process in more detail and clarify what percentage of your certificate issuance occurs through the automation process?
(Comment) A contributing factor was a configuration set in 2019. The timeline should have been expanded to include when the hierarchy was created, when the certificate profile was created, modified, and last reviewed, and when the relevant sections of applicable PKI policies (e.g., the CA/B Forum TLS Baseline Requirements) changed that resulted in this issue being categorized as misissuance.
(Q2) Regarding RCA Contributing Factor #1 (Insufficient checks after changes), your analysis states that the emailAddress attribute was configured as "optional" in your system in 2019, based on the BRs at the time, but this was a deviation from your approved CP/CPS (most likely this version).
- a. Why did your internal processes allow for a system configuration that did not match the approved CP/CPS profile for over five years?
- b. Your report mentions that manual checks only focused on modifications, not a full profile review. This appears to be a significant, long-standing process failure. Why was this gap in your change control process never identified during the annual audits, or in previous self-audits?
(Q3) In the "What didn’t go well" Section you state: "The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight." However, the report also states that a manual review by a validation specialist failed to identify the extra attribute. This seems contradictory. Could you clarify the failure? Did the validation specialist fail to perform the check, or did they perform it incorrectly?
(Q4) The Action Items seem like they could be a good start, but some lack the specificity needed to ensure they will be effective.
-
a. How will you ensure that the updated "certificate profile management procedure" in Item #2 is consistently followed and audited to prevent a similar drift between documentation and implementation in the future?
-
b. Adding pkimetal is described in Item #4, but can you help us understand what barriers prevented Agence Nationale de Certification Electronique from adopting pkimetal sooner? More generally speaking, given the past misissuance events, why did Agence Nationale de Certification Electronique not adopt additional and more up-to-date linting solutions (like pkilint or pkimetal) sooner?
-
c. Training as detailed in Item #5 is often considered a weak control for systemic issues. This incident appears to stem from fundamental process and configuration failures, not just a lack of knowledge. What more robust, systemic controls are you considering beyond training to prevent recurrence?
(Comment) This type of misissuance is disappointing for two reasons:
-
1. Over the past two years, there has been no shortage of signal that linters are not and will never be complete solutions (“Don’t blame the linter.”). Further, it’s been made very clear that the linters described in use in this bug (i.e., cablint and zlint) have fallen behind newer tools and that they do not cover the set of changes introduced in TLS BR 2.0 (examples 1, 2, and 3). This point was also emphasized at the most recent F2F by one of Zlint's creators.
-
2. Similarly, there have been numerous incidents disclosed related to relying on CSR contents for anything other than the public key resulting in misissuance (example).
(Q5) Given the above, is “N/A” still considered an appropriate response for the Related Incidents section?
(Q6) Can you help us understand how Agence Nationale de Certification Electronique is following reports filed to Bugzilla and applying lessons learned to its own policies and practices? Does this incident report highlight improvement is necessary? If so, maybe there is an opportunity for another Action Item.
(Q7) Does Agence Nationale de Certification Electronique intend to change the way it relies on CSRs to prevent this type of misissuance going forward? If so, maybe there is an opportunity for another Action Item.
|
|
Assignee | |
Comment 6•5 months ago
|
||
(In reply to chrome-root-program from comment #5)
(Q1) In the Impact Section it’s stated: “Certificate issuance was stopped for certificates that are not issued through the automation process and it will resume when Action item #1 is put in place.” Could you describe the automation process in more detail and clarify what percentage of your certificate issuance occurs through the automation process?
The automation process is based on the ACME protocol. The OV ACME Directory URL is already declared in CCADB.
Currently, we are only issuing test certificates via the automation process in order to comply with Google Chrome’s requirements.
The certificates that were issued through the ACME process are the following:
https://crt.sh/?id=18559591473
https://crt.sh/?id=19136897106
https://crt.sh/?id=19368416765
https://crt.sh/?id=19791182217
https://crt.sh/?id=20046364727
https://crt.sh/?id=20153482661
(Comment) A contributing factor was a configuration set in 2019. The timeline should have been expanded to include when the hierarchy was created, when the certificate profile was created, modified, and last reviewed, and when the relevant sections of applicable PKI policies (e.g., the CA/B Forum TLS Baseline Requirements) changed that resulted in this issue being categorized as misissuance.
We will add the requested timeline in the update version of the full incident report.
(Q2) Regarding RCA Contributing Factor #1 (Insufficient checks after changes), your analysis states that the emailAddress attribute was configured as "optional" in your system in 2019, based on the BRs at the time, but this was a deviation from your approved CP/CPS (most likely this version).
- a. Why did your internal processes allow for a system configuration that did not match the approved CP/CPS profile for over five years?
The configuration drift was not caught because our change control process focused only on logging explicit modifications, not comparing the full configuration against the CP/CPS certificate profile. Over time, the drift remained undetected.
Prior to the publication of Version 01 that you referenced above, there existed a draft Version 00, to which members of the Policy Authority made modifications in review mode, ensuring that all changes were controlled and documented. In the early drafts of Version 00, the certificate profile matched the system configuration. However, during the review process, the Policy Authority decided to remove the emailAddress attribute from the profile. This modification was approved in the draft and carried forward into the published Version 01. However, this change was not accompanied by a formal change request in the change management platform.
This scenario had already been considered in our risk assessment (prior to this incident), where the lack of human resources was identified as a major contributing factor. As a mitigation measure, we have progressively expanded our technical team — for example, the PKI department experienced a 200% growth rate between 2019 and 2025.
- b. Your report mentions that manual checks only focused on modifications, not a full profile review. This appears to be a significant, long-standing process failure. Why was this gap in your change control process never identified during the annual audits, or in previous self-audits?
Annual internal audits and prior self-audits focused on reviewing change logs and documentation changes rather than comparing the entire certificate profile configured in the system against the CP/CPS. Since there were no logged configuration changes regarding this attribute, internal auditors assumed alignment. The current incident has highlighted the shortcoming of this approach. We already put Action item #2 to address this process failure.
(Q3) In the "What didn’t go well" Section you state: "The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight." However, the report also states that a manual review by a validation specialist failed to identify the extra attribute. This seems contradictory. Could you clarify the failure? Did the validation specialist fail to perform the check, or did they perform it incorrectly?
There are two points of failures identified:
-
Our internal procedure does not have a formal step for the validation specialist to check the certificate post-issuance, since we believe that pre-issuance automated checks and system validators will detect non-compliances if they exist.
-
Beside the automated checks, we have, in our internal procedure, a formal step of reviewing CSR contents prior to issuance. This extra manual check was added following a risk assessment of automated validators failure scenario. However, for this specific certificate, they performed it incorrectly since they failed to detect the additional attribute.
(Q4) The Action Items seem like they could be a good start, but some lack the specificity needed to ensure they will be effective.
- a. How will you ensure that the updated "certificate profile management procedure" in Item #2 is consistently followed and audited to prevent a similar drift between documentation and implementation in the future?
To prevent a recurrence of such configuration drift, the change control process will include a step in which the system profile is compared against the approved profile in the CP/CPS, conducted by an internal auditor.
In addition, an action item will be added to the internal audit procedure to verify the certificate profile directly within the system, in the annual internal audit.
- b. Adding pkimetal is described in Item #4, but can you help us understand what barriers prevented Agence Nationale de Certification Electronique from adopting pkimetal sooner? More generally speaking, given the past misissuance events, why did Agence Nationale de Certification Electronique not adopt additional and more up-to-date linting solutions (like pkilint or pkimetal) sooner?
In the last quarter of 2024, we evaluated the integration of the pkimetal linting tool into our CA environment. At that time, our existing validators already included ROCA, Debian Weak Key, zlint, and cablint linting tools. Consequently, we determined that pkilint would be the only additional tool to implement.
Configuration testing for pkilint was conducted in January and February 2025. During these tests, several issues were identified, and the change request was subsequently placed on hold. This decision was made to prioritize the implementation and testing of higher-impact changes, including MPIC and ACME. Following this incident, we have allocated resources to integrate the pkimetal linting tool by September 8, 2025.
Action Item #4 seeks to implement the pkimetal linting tool as an additional component to complement the existing tools listed above.
- c. Training as detailed in Item #5 is often considered a weak control for systemic issues. This incident appears to stem from fundamental process and configuration failures, not just a lack of knowledge. What more robust, systemic controls are you considering beyond training to prevent recurrence?
We acknowledge this concern, which is why Action Items #1 and #4 have been specifically designed to prevent recurrence of the issue.
(Comment) This type of misissuance is disappointing for two reasons:
1. Over the past two years, there has been no shortage of signal that linters are not and will never be complete solutions (“Don’t blame the linter.”). Further, it’s been made very clear that the linters described in use in this bug (i.e., cablint and zlint) have fallen behind newer tools and that they do not cover the set of changes introduced in TLS BR 2.0 (examples 1, 2, and 3). This point was also emphasized at the most recent F2F by one of Zlint's creators.
2. Similarly, there have been numerous incidents disclosed related to relying on CSR contents for anything other than the public key resulting in misissuance (example).
We fully acknowledge this and are aware of similar incidents affecting other CAs in the past, which is why:
- The fact that the linting tools did not prevent issuance was not identified as a root cause for this incident, nor do we attribute blame to these tools. Rather, this information was included solely for contextual clarity within the incident description and as a direct response to the first comment.
- The presence of incorrect CSR content was not presented in a manner that assigns blame to applicants. Our root cause analysis focuses on deficiencies within our own controls.
- We consider this incident an opportunity for self-reflection and continuous improvement, despite regularly reviewing other CAs’ incidents and proactively auditing our own configurations to avoid similar errors
(Q5) Given the above, is “N/A” still considered an appropriate response for the Related Incidents section?
After reviewing your question, we realized that we had misunderstood the scope of this section. We interpreted it as referring exclusively to incidents within our own operations. Since we had not experienced any mis-issuance incidents prior to this one, we indicated “N/A.” We will correct this in the updated version of the incident report.
(Q6) Can you help us understand how Agence Nationale de Certification Electronique is following reports filed to Bugzilla and applying lessons learned to its own policies and practices? Does this incident report highlight improvement is necessary? If so, maybe there is an opportunity for another Action Item.
We review the Bugzilla incident dashboard on a weekly basis to identify cases that may highlight potential issues relevant to our organization. We also have an ongoing initiative to expand the compliance team to ensure that all available information (from google groups, newsletters, etc.) is thoroughly assessed and addressed.
(Q7) Does Agence Nationale de Certification Electronique intend to change the way it relies on CSRs to prevent this type of misissuance going forward? If so, maybe there is an opportunity for another Action Item.
We believe that the current measures along with the action items identified will prevent this type of mis-issuance going forward.
|
|
||
Comment 7•5 months ago
|
||
Thank you for providing the answers in Comment 6.
Comment 6 states that the risk of a gap between Agence Nationale de Certification Electronique’s CP/CPS and its system configuration was previously identified, with "lack of human resources" cited as a major contributing factor. The response then notes that expanding the team was the mitigation.
While we acknowledge that an under-resourced team is a risk, simply increasing headcount is often an insufficient control for systemic process failures. Human-based controls are prone to error and inconsistency, as demonstrated by the validation specialist's failure to detect the attribute in this very incident. The ideal solution for configuration integrity is robust, automated enforcement.
(Q1): Beyond increasing staff, what automated technical controls are Agence Nationale de Certification Electronique implementing to continuously validate live system configurations against the approved CP/CPS profiles? Relying on a manual check, even if performed more often, does not seem to address the root cause as effectively as automated validation.
Comment 6 proposes to add an Action Item to the internal audit procedure to verify the certificate profile annually.
(Q2): An annual internal audit means a critical configuration drift, like the one that caused this incident, could persist for up to 364 days before internal detection. Given that this incident proved such a drift can go unnoticed for over five years by both internal and external audits, why does Agence Nationale de Certification Electronique consider a periodic annual check a sufficient control, rather than more frequent, automated monitoring?
The delay in implementing a modern linter remains a concern given the importance of doing so as demonstrated by numerous incident reports over the last 2 years.
(Q3): Comment 6 states that Agence Nationale de Certification Electronique began pkilint testing in January/February 2025. However, by June 2024, it was widely understood from public incidents that older linters had significant coverage gaps. Can you explain the apparent delay in adopting a modern linter?
(Q4): Comment 6 states "several issues were identified" leading to the linting upgrade project being placed on hold. Please describe the specific nature of these technical issues.
We believe that the current measures along with the action items identified will prevent this type of mis-issuance going forward.
Comment: We will again emphasize that the industry best practice, reinforced by numerous public incidents (such as Bug 1944436), is to treat the CSR only as a vehicle for transmitting a public key. We are not confident the existing and proposed action items offer comparable strength of preventive control as reducing technical reliance on CSRs during the issuance process.
|
|
Assignee | |
Comment 8•4 months ago
|
||
Comment 6 states that the risk of a gap between Agence Nationale de Certification Electronique’s CP/CPS and its system configuration was previously identified, with "lack of human resources" cited as a major contributing factor. The response then notes that expanding the team was the mitigation.
While we acknowledge that an under-resourced team is a risk, simply increasing headcount is often an insufficient control for systemic process failures. Human-based controls are prone to error and inconsistency, as demonstrated by the validation specialist's failure to detect the attribute in this very incident. The ideal solution for configuration integrity is robust, automated enforcement.
(Q1): Beyond increasing staff, what automated technical controls are Agence Nationale de Certification Electronique implementing to continuously validate live system configurations against the approved CP/CPS profiles? Relying on a manual check, even if performed more often, does not seem to address the root cause as effectively as automated validation.
Comment 6 proposes to add an Action Item to the internal audit procedure to verify the certificate profile annually.
(Q2): An annual internal audit means a critical configuration drift, like the one that caused this incident, could persist for up to 364 days before internal detection. Given that this incident proved such a drift can go unnoticed for over five years by both internal and external audits, why does Agence Nationale de Certification Electronique consider a periodic annual check a sufficient control, rather than more frequent, automated monitoring?
Comment: We will again emphasize that the industry best practice, reinforced by numerous public incidents (such as Bug 1944436), is to treat the CSR only as a vehicle for transmitting a public key. We are not confident the existing and proposed action items offer comparable strength of preventive control as reducing technical reliance on CSRs during the issuance process.
We would like to provide additional clarification to our previous statements. One of the root causes identified in our risk assessment, particularly regarding gaps between documentation and system configurations, was the “lack of human resources.” Accordingly, the corresponding mitigation action was to “increase human resources.” Nonetheless, other root causes were also identified, for which appropriate mitigation and preventive measures have been implemented.
Our previous statements may also have lacked clarity with respect to Action Item #1. We already have an automated control in place that prevents the issuance of certificates not aligned with the pre-configured certificate profile. However, because the emailAddress attribute was marked as optional, the certificate issuance was not aborted for the certificate request in question. Following the update of the certificate profile in the CA system, the automated control will now prevent any similar mis-issuance.
We also would like to emphasize the following:
- Our operations rely on both automated and human-based controls, thereby reducing the likelihood of such incidents.
- Automated monitoring is already in place to detect any changes in our system configurations, including certificate profiles.
- The new action item related to the annual internal audit is complementary to the existing measures, providing more frequent checks—when combined with change-control procedures—and ensuring broader, multi-faceted verification.
The delay in implementing a modern linter remains a concern given the importance of doing so as demonstrated by numerous incident reports over the last 2 years.
(Q3): Comment 6 states that Agence Nationale de Certification Electronique began pkilint testing in January/February 2025. However, by June 2024, it was widely understood from public incidents that older linters had significant coverage gaps. Can you explain the apparent delay in adopting a modern linter?
The adoption of PKI Lint was delayed due to mandatory priorities established by the CA/Browser Forum Baseline Requirements. In particular, implementation of Multi-Perspective Issuance Corroboration (MPIC) by March 15, 2025, required significant engineering resources to install, test and integrate the MPIC API into our CA software.
We also prioritized the implementation of the ACME protocol to improve automated certificate issuance. Given the presence of existing linting tools already in production, we assessed that immediate PKI Lint deployment could be safely deferred without compromising our ability to detect non-compliances. Consequently, PKI Lint implementation was scheduled following completion of the MPIC and ACME initiatives.
(Q4): Comment 6 states "several issues were identified" leading to the linting upgrade project being placed on hold. Please describe the specific nature of these technical issues.
During the initial testing of pkilint, a wildcard certificate issued by our CA triggered an error when analyzed with the lint_pkix_cert command, indicating non-compliance with the “preferred name syntax” defined in RFC 1034 (section 3.5) and RFC 1123 (section 2.1). The initial root cause analysis was inconclusive, which led to placing the implementation of pkilint on hold. A subsequent, more detailed analysis revealed that the issue resulted from the use of an inappropriate linting profile.
|
|
Assignee | |
Comment 9•4 months ago
|
||
Full Incident Report
Summary
-
CA Owner CCADB unique ID: A000785
-
Incident description:
- As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
The affected certificate was issued on May 27th, 2025, and was promptly revoked on August 6th, 2025, the same day the issue was detected. - The self-audit covers all SSL certificates that we issue and is not limited to a sample. It is conducted on a quarterly basis as stated in the CP/CPS.
- After performing the necessary checks in order to determine whether any other certificates have the same issue, we confirmed that there are no other occurrences of this non-compliance since we started issuance with this CA hierarchy.
- We use the zlint v3.6.6 and cablint v1.8.0 tools in the issuance process. After further checks, only the cablint generated an INFO level log entry for this certificate:
cablint INFO Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
zlint WARNING Subscriber Certificate: commonName is NOT RECOMMENDED.-
Our linting validator is configured to abort the issuance process only when an ERROR-level finding is reported.
-
The client submitted a CSR containing the emailAddress attribute and did not comply with the expected syntax:
a. The CSR content is manually reviewed by a validation specialist prior to issuance. While similar issues have been flagged successfully in the past, the control failed in this instance, as the additional attribute was not identified by the reviewer.
b. In addition, the system performs an automated check by comparing the CSR against a pre-configured certificate profile within the CA application. However, in this profile, the emailAddress attribute was marked as optional. This configuration was initially established in 2019 when the CA hierarchy was created. All profile changes are documented, logged, and monitored. Based on this, it was concluded that the configuration of the emailAddress attribute as optional originated from the initial profile setup.
-
No prior mis-issuance incidents have been recorded for this CA hierarchy. Previous incident reports related to this hierarchy in Bugzilla concerned CRL and the OCSP responder availability, rather than certificate content or compliance issues.
-
This issue impacted only a single certificate, which was promptly revoked on the same day (August 6th, 2025).
- As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
-
Timeline summary:
- Non-compliance start date: May 27th 2025
- Non-compliance identified date: August 6th 2025
- Non-compliance end date: August 6th 2025
-
Relevant policies:
- Self audit : section 8.7 in CA/B Forum TLS BRs v2.1.6 and section 8.7 of our CP/CPS v06 ,
- Subscriber Certificate profile: Section 7.1.2.7.4 and Appendix B of our CP/CPS v06 .
-
Source of incident disclosure:
Self-reported.
Impact
- Total number of certificates: 01
- Total number of "remaining valid" certificates: 0
- Affected certificate types: This incident affects an OV SSL certificate.
- Incident heuristic: The link to the affected certificate on crt.sh : https://crt.sh/?id=18652895741
- Was issuance stopped in response to this incident, and why or why not?: Certificate issuance was stopped for certificates that are not issued through the automation process and resumed when Action item #1 was put in place.
- Analysis: N/A
- Additional considerations: N/A
Timeline
2019-04-12: CP/CPS version 01 was approved (Profile does not include emailAddress attribute)
2019-04-18 09:42 UTC : CA hierarchy created
2019-04-22 15:55: UTC Subscriber Certificate Profile created in the CA system (Profile includes emailAddress attribute)
2019-10-03 13:58 UTC: First Subscriber certificate (OV SSL) was issued
2025-06-25 14:00 UTC: Subscriber Certificate Profile was last reviewed
2025- 05-27 11:59 UTC : Subscriber Certificate with emailAddress attribute was issued.
2025- 08-06 07:47 UTC : Internal Auditor detects the issue and issuance is ceased for certificates that are not issued through the automation process.
2025- 08-06 08:37 UTC : The scope and impact of the incident were concluded.
2025- 08-06 11:17 UTC : The affected certificate was revoked.
Related Incidents
Examples of related incidents from other CAs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1940957
https://bugzilla.mozilla.org/show_bug.cgi?id=1887008
https://bugzilla.mozilla.org/show_bug.cgi?id=1944436
https://bugzilla.mozilla.org/show_bug.cgi?id=1896596
https://bugzilla.mozilla.org/show_bug.cgi?id=1889672
https://bugzilla.mozilla.org/show_bug.cgi?id=1843268
https://bugzilla.mozilla.org/show_bug.cgi?id=1882256
https://bugzilla.mozilla.org/show_bug.cgi?id=1839105
Root Cause Analysis
Contributing Factor #: 1 - Insufficient checks after changes
- Description:
The emailAddress attribute was configured as optional in the subscriber certificate profile when the CA hierarchy was created. At that time, SSL certificate issuance was governed by version 1.6.5 of the CA/B Forum TLS Baseline Requirements (April 2019). According to section 7.1.4.2.2(j):
“Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.”.
Based on this provision, the inclusion of the emailAddress attribute was considered acceptable, and it was marked as optional in the system’s certificate profile by the PKI administrators. However, the approved profile documented in the CP/CPS did not include this attribute.
During validation and self-audit processes, both validation specialists and internal auditors reference only the approved CP/CPS profile (and other internal approved documents) when reviewing certificates / certificate requests.
All changes to certificate profiles are subject to a formal change management process, and the monitoring system automatically reports any modifications with a detailed description.
As a result, manual checks during change control focused only on modifications, not on the full profile. The administrator relied on the assumption that the original, approved configuration remained valid unless formally changed, trusting that any unauthorized change would trigger an alert.
-
Timeline: Since the creation of the CA hierarchy.
-
Detection:
This limitation in the change-control step was not previously identified, as no unauthorized changes had occurred that would have triggered an alert. -
Interaction with other factors: N/A
Contributing Factor #: 2 Insufficient checks after issuance
-
Description:
After certificate issuance, there is no formal step to verify that the certificate content aligns with the subscriber profile defined in the CP/CPS. -
Timeline: The validation specialists team relies on pre-issuance checks and system validators to detect non-compliance. As a result, post-issuance content review is typically overlooked.
-
Detection: No other mis-issuance incidents have occurred since the creation of this CA hierarchy. As a result, the absence of post-issuance checks had not been identified as a weakness prior to this incident.
-
Interaction with other factors: Had post-issuance checks been in place, the issue could have been detected and the certificate revoked immediately after issuance, even if pre-issuance controls had failed.
Lessons Learned
-
What went well:
- The self-audit process successfully identified the non-compliance and triggered timely internal communication.
- The affected certificate was revoked within 24 hours of detection.
-
What didn’t go well:
- The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight.
- Although the validation process involves two validation specialists, neither identified the presence of the emailAddress attribute in this particular request.
-
Where we got lucky: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Update the subscriber certificate profile to omit the emailAddress attribute | Mitigate | Root Cause # 1 | Conduct a test of the certificate issuance process using a CSR that includes the emailAddress attribute, to verify whether the system aborts issuance in such cases. | 2025-08-12 | Complete |
| Update the certificate profile management procedure to check all the certificate profile in the change control step | Prevent | Root Cause # 1 | Certificate profile matches CP/CPS certificate profile | 2025-08-15 | Complete |
| Update the validation procedure to formally check the content of the certificate (post-issuance) | Detect | Root Cause # 2 | All certificates are checked upon issuance | 2025-08-15 | Complete |
| Add the pkimetal linting tool in the issuance process | Detect | Root Cause # 1 | The linting configuration should flag non-compliance as an ERROR, not just a WARNING or INFO | 2025-09-08 | Ongoing |
| Include the lesson learnt from this incident in the annual training of trusted roles | Prevent | Root Cause # 1&2 | High scores in evaluation tests of participants | 2025-08-29 | Ongoing |
| Add within the internal audit checklist an item related to the verification of the certificate profile directly within the system | Detect | Root Cause # 1 | The certificate profile in the system is identical to the CP/CPS | 2025-09-08 | Ongoing |
Appendix
Uploaded CSV file
|
|
Assignee | |
Comment 10•4 months ago
|
||
Full Incident Report
Summary
-
CA Owner CCADB unique ID: A000785
-
Incident description:
- As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
- The affected certificate was issued on May 27th, 2025, and was promptly revoked on August 6th, 2025, the same day the issue was detected.
- The self-audit covers all SSL certificates that we issue and is not limited to a sample. It is conducted on a quarterly basis as stated in the CP/CPS.
- After performing the necessary checks in order to determine whether any other certificates have the same issue, we confirmed that there are no other occurrences of this non-compliance since we started issuance with this CA hierarchy.
- We use the zlint v3.6.6 and cablint v1.8.0 tools in the issuance process. After further checks, only the cablint generated an INFO level log entry for this certificate:
cablint INFO Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
zlint WARNING Subscriber Certificate: commonName is NOT RECOMMENDED.-
Our linting validator is configured to abort the issuance process only when an ERROR-level finding is reported.
-
The client submitted a CSR containing the emailAddress attribute and did not comply with the expected syntax.
a. The CSR content is manually reviewed by a validation specialist prior to issuance. While similar issues have been flagged successfully in the past, the control failed in this instance, as the additional attribute was not identified by the reviewer.
b. In addition, the system performs an automated check by comparing the CSR against a pre-configured certificate profile within the CA application. However, in this profile, the emailAddress attribute was marked as optional. This configuration was initially established in 2019 when the CA hierarchy was created. All profile changes are documented, logged, and monitored. Based on this, it was concluded that the configuration of the emailAddress attribute as optional originated from the initial profile setup.
-
No prior mis-issuance incidents have been recorded for this CA hierarchy. Previous incident reports related to this hierarchy in Bugzilla concerned CRL and the OCSP responder availability, rather than certificate content or compliance issues.
-
This issue impacted only a single certificate, which was promptly revoked on the same day (August 6th, 2025).
-
Timeline summary:
- Non-compliance start date: May 27th 2025
- Non-compliance identified date: August 6th 2025
- Non-compliance end date: August 6th 2025
-
Relevant policies:
- Self audit : section 8.7 in CA/B Forum TLS BRs v2.1.6 and section 8.7 of our CP/CPS v06 [https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf ],
- Subscriber Certificate profile: Section 7.1.2.7.4 and Appendix B of our CP/CPS v06 [https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf ].
-
Source of incident disclosure:
Self-reported.
Impact
- Total number of certificates: 01
- Total number of "remaining valid" certificates: 0
- Affected certificate types: This incident affects an OV SSL certificate.
- Incident heuristic: The link to the affected certificate on crt.sh : https://crt.sh/?id=18652895741
- Was issuance stopped in response to this incident, and why or why not?: Certificate issuance was stopped for certificates that are not issued through the automation process and it will resume when Action item #1 is put in place.
- Analysis: N/A
- Additional considerations: N/A
Timeline
2019-04-12 CP/CPS version 01 was approved (Profile does note include EmailAddress attribute)
2019-04-18 09:42 UTC : CA hierarchy created
2019-04-22 15:55 UTC Subscriber Certificate Profile created in the CA system (Profile includes EmailAddress attribute)
2019-10-03 13:58 UTC: First Subscriber certificate (OV SSL) was issued
2025-06-25 14:00 UTC: Subscriber Certificate Profile was last reviewed
2025- 05-27 11:59 UTC : Subscriber Certificate with emailAddress attribute was issued.
2025- 08-06 07:47 UTC : Internal Auditor detects the issue and issuance is ceased for certificates that are not issued through the automation process.
2025- 08-06 08:37 UTC : The scope and impact of the incident were concluded.
2025- 08-06 11:17 UTC : The affected certificate was revoked.
Related Incidents
Examples of related incidents from other CAs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1940957
https://bugzilla.mozilla.org/show_bug.cgi?id=1887008
https://bugzilla.mozilla.org/show_bug.cgi?id=1944436
https://bugzilla.mozilla.org/show_bug.cgi?id=1896596
https://bugzilla.mozilla.org/show_bug.cgi?id=1889672
https://bugzilla.mozilla.org/show_bug.cgi?id=1843268
https://bugzilla.mozilla.org/show_bug.cgi?id=1882256
https://bugzilla.mozilla.org/show_bug.cgi?id=1839105
Root Cause Analysis
Contributing Factor #: 1 - Insufficient checks after changes
- Description:
The emailAddress attribute was configured as optional in the subscriber certificate profile when the CA hierarchy was created. At that time, SSL certificate issuance was governed by version 1.6.5 of the CA/B Forum TLS Baseline Requirements (April 2019). According to section 7.1.4.2.2(j):
Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.
Based on this provision, the inclusion of the emailAddress attribute was considered acceptable, and it was marked as optional in the system’s certificate profile by the PKI administrators. However, the approved profile documented in the CP/CPS did not include this attribute.
During validation and self-audit processes, both validation specialists and internal auditors reference only the approved CP/CPS profile (and other internal approved documents) when reviewing certificates / certificate requests.
All changes to certificate profiles are subject to a formal change management process, and the monitoring system automatically reports any modifications with a detailed description.
As a result, manual checks during change control focused only on modifications, not on the full profile. The administrator relied on the assumption that the original, approved configuration remained valid unless formally changed, trusting that any unauthorized change would trigger an alert.
-
Timeline: Since the creation of the CA hierarchy.
-
Detection:
This limitation in the change-control step was not previously identified, as no unauthorized changes had occurred that would have triggered an alert. -
Interaction with other factors: N/A
Contributing Factor #: 2 Insufficient checks after issuance
- Description:
After certificate issuance, there is no formal step to verify that the certificate content aligns with the subscriber profile defined in the CP/CPS. - Timeline: The validation specialists team relies on pre-issuance checks and system validators to detect non-compliance. As a result, post-issuance content review is typically overlooked.
- Detection: No other mis-issuance incidents have occurred since the creation of this CA hierarchy. As a result, the absence of post-issuance checks had not been identified as a weakness prior to this incident.
- Interaction with other factors: Had post-issuance checks been in place, the issue could have been detected and the certificate revoked immediately after issuance, even if pre-issuance controls had failed.
Lessons Learned
-
What went well:
-
The self-audit process successfully identified the non-compliance and triggered timely internal communication.
-
The affected certificate was revoked within 24 hours of detection.
-
-
What didn’t go well:
- The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight.
- Although the validation process involves two validation specialists, neither identified the presence of the emailAddress attribute in this particular request.
-
Where we got lucky: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Update the subscriber certificate profile to omit the emailAddress attribute | Mitigate | Root Cause # 1 | Conduct a test of the certificate issuance process using a CSR that includes the emailAddress attribute, to verify whether the system aborts issuance in such cases. | 2025-08-11 | Complete |
| Update the certificate profile management procedure to check all the certificate profile in the change control step | Prevent | Root Cause # 1 | Certificate profile matches CP/CPS certificate profile | 2025-08-15 | Complete |
| Update the validation procedure to formally check the content of the certificate (post-issuance) | Detect | Root Cause # 2 | All certificates are checked upon issuance | 2025-08-15 | Complete |
| Add the pkimetal linting tool in the issuance process | Detect | Root Cause # 1 | The linting configuration should flag non-compliance as an ERROR, not just a WARNING or INFO | 2025-09-08 | Ongoing |
| Include the lesson learnt from this incident in the annual training of trusted roles | Prevent | Root Cause # 1&2 | High scores in evaluation tests of participants | 2025-08-29 | Complete |
| Add within the internal audit checklist an item related to the verification of the certificate profile directly within the system | Detect | Root Cause # 1 | The certificate profile in the system is identical to the CP/CPS | 2025-09-08 | Ongoing |
Appendix
Uploaded CSV file
|
|
Assignee | |
Comment 11•4 months ago
|
||
This is an update to the incident report. Changes are highlighted in bold.
Full Incident Report
Summary
-
CA Owner CCADB unique ID: A000785
-
Incident description:
- As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
The affected certificate was issued on May 27th, 2025, and was promptly revoked on August 6th, 2025, the same day the issue was detected. - The self-audit covers all SSL certificates that we issue and is not limited to a sample. It is conducted on a quarterly basis as stated in the CP/CPS.
- After performing the necessary checks in order to determine whether any other certificates have the same issue, we confirmed that there are no other occurrences of this non-compliance since we started issuance with this CA hierarchy.
- We use the zlint v3.6.6 and cablint v1.8.0 tools in the issuance process. After further checks, only the cablint generated an INFO level log entry for this certificate:
cablint INFO Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
zlint WARNING Subscriber Certificate: commonName is NOT RECOMMENDED.-
Our linting validator is configured to abort the issuance process only when an ERROR-level finding is reported.
-
The client submitted a CSR containing the emailAddress attribute and did not comply with the expected syntax:
a. The CSR content is manually reviewed by a validation specialist prior to issuance. While similar issues have been flagged successfully in the past, the control failed in this instance, as the additional attribute was not identified by the reviewer.
b. In addition, the system performs an automated check by comparing the CSR against a pre-configured certificate profile within the CA application. However, in this profile, the emailAddress attribute was marked as optional. This configuration was initially established in 2019 when the CA hierarchy was created. All profile changes are documented, logged, and monitored. Based on this, it was concluded that the configuration of the emailAddress attribute as optional originated from the initial profile setup.
-
No prior mis-issuance incidents have been recorded for this CA hierarchy. Previous incident reports related to this hierarchy in Bugzilla concerned CRL and the OCSP responder availability, rather than certificate content or compliance issues.
-
This issue impacted only a single certificate, which was promptly revoked on the same day (August 6th, 2025).
- As part of the self audit process for SSL certificates, the internal auditor identified, on August 6th, 2025, a non-compliance issue affecting one subscriber certificate. Specifically, the Subject attributes of this certificate include the “emailAddress” attribute, which is not explicitly listed as “permitted” in the subscriber certificate profile as defined in the applicable version of the CP/CPS.
-
Timeline summary:
- Non-compliance start date: May 27th 2025
- Non-compliance identified date: August 6th 2025
- Non-compliance end date: August 6th 2025
-
Relevant policies:
- Self audit : section 8.7 in CA/B Forum TLS BRs v2.1.6 and section 8.7 of our CP/CPS v06 ,
- Subscriber Certificate profile: Section 7.1.2.7.4 and Appendix B of our CP/CPS v06 .
-
Source of incident disclosure:
Self-reported.
Impact
- Total number of certificates: 01
- Total number of "remaining valid" certificates: 0
- Affected certificate types: This incident affects an OV SSL certificate.
- Incident heuristic: The link to the affected certificate on crt.sh : https://crt.sh/?id=18652895741
- Was issuance stopped in response to this incident, and why or why not?: Certificate issuance was stopped for certificates that are not issued through the automation process and resumed when Action item #1 was put in place.
- Analysis: N/A
- Additional considerations: N/A
Timeline
2019-04-12: CP/CPS version 01 was approved (Profile does not include emailAddress attribute)
2019-04-18 09:42 UTC : CA hierarchy created
2019-04-22 15:55: UTC Subscriber Certificate Profile created in the CA system (Profile includes emailAddress attribute)
2019-10-03 13:58 UTC: First Subscriber certificate (OV SSL) was issued
2025-06-25 14:00 UTC: Subscriber Certificate Profile was last reviewed
2025- 05-27 11:59 UTC : Subscriber Certificate with emailAddress attribute was issued.
2025- 08-06 07:47 UTC : Internal Auditor detects the issue and issuance is ceased for certificates that are not issued through the automation process.
2025- 08-06 08:37 UTC : The scope and impact of the incident were concluded.
2025- 08-06 11:17 UTC : The affected certificate was revoked.
Related Incidents
Examples of related incidents from other CAs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1940957
https://bugzilla.mozilla.org/show_bug.cgi?id=1887008
https://bugzilla.mozilla.org/show_bug.cgi?id=1944436
https://bugzilla.mozilla.org/show_bug.cgi?id=1896596
https://bugzilla.mozilla.org/show_bug.cgi?id=1889672
https://bugzilla.mozilla.org/show_bug.cgi?id=1843268
https://bugzilla.mozilla.org/show_bug.cgi?id=1882256
https://bugzilla.mozilla.org/show_bug.cgi?id=1839105
Root Cause Analysis
Contributing Factor #: 1 - Insufficient checks after changes
- Description:
The emailAddress attribute was configured as optional in the subscriber certificate profile when the CA hierarchy was created. At that time, SSL certificate issuance was governed by version 1.6.5 of the CA/B Forum TLS Baseline Requirements (April 2019). According to section 7.1.4.2.2(j):
“Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.”.
Based on this provision, the inclusion of the emailAddress attribute was considered acceptable, and it was marked as optional in the system’s certificate profile by the PKI administrators. However, the approved profile documented in the CP/CPS did not include this attribute.
During validation and self-audit processes, both validation specialists and internal auditors reference only the approved CP/CPS profile (and other internal approved documents) when reviewing certificates / certificate requests.
All changes to certificate profiles are subject to a formal change management process, and the monitoring system automatically reports any modifications with a detailed description.
As a result, manual checks during change control focused only on modifications, not on the full profile. The administrator relied on the assumption that the original, approved configuration remained valid unless formally changed, trusting that any unauthorized change would trigger an alert.
-
Timeline: Since the creation of the CA hierarchy.
-
Detection:
This limitation in the change-control step was not previously identified, as no unauthorized changes had occurred that would have triggered an alert. -
Interaction with other factors: N/A
Contributing Factor #: 2 Insufficient checks after issuance
-
Description:
After certificate issuance, there is no formal step to verify that the certificate content aligns with the subscriber profile defined in the CP/CPS. -
Timeline: The validation specialists team relies on pre-issuance checks and system validators to detect non-compliance. As a result, post-issuance content review is typically overlooked.
-
Detection: No other mis-issuance incidents have occurred since the creation of this CA hierarchy. As a result, the absence of post-issuance checks had not been identified as a weakness prior to this incident.
-
Interaction with other factors: Had post-issuance checks been in place, the issue could have been detected and the certificate revoked immediately after issuance, even if pre-issuance controls had failed.
Lessons Learned
-
What went well:
- The self-audit process successfully identified the non-compliance and triggered timely internal communication.
- The affected certificate was revoked within 24 hours of detection.
-
What didn’t go well:
- The validation team placed excessive reliance on automated system controls, rather than maintaining a balanced approach with manual oversight.
- Although the validation process involves two validation specialists, neither identified the presence of the emailAddress attribute in this particular request.
-
Where we got lucky: N/A
Action Items
| Action Item | Kind | Corresponding Root Cause(s) | Evaluation Criteria | Due Date | Status |
|---|---|---|---|---|---|
| Update the subscriber certificate profile to omit the emailAddress attribute | Mitigate | Root Cause # 1 | Conduct a test of the certificate issuance process using a CSR that includes the emailAddress attribute, to verify whether the system aborts issuance in such cases. | 2025-08-11 | Complete |
| Update the certificate profile management procedure to check all the certificate profile in the change control step | Prevent | Root Cause # 1 | Certificate profile matches CP/CPS certificate profile | 2025-08-15 | Complete |
| Update the validation procedure to formally check the content of the certificate (post-issuance) | Detect | Root Cause # 2 | All certificates are checked upon issuance | 2025-08-15 | Complete |
| Add the pkimetal linting tool in the issuance process | Detect | Root Cause # 1 | The linting configuration should flag non-compliance as an ERROR, not just a WARNING or INFO | 2025-09-03 | Complete |
| Include the lesson learnt from this incident in the annual training of trusted roles | Prevent | Root Cause # 1&2 | High scores in evaluation tests of participants | 2025-08-29 | Complete |
| Add within the internal audit checklist an item related to the verification of the certificate profile directly within the system | Detect | Root Cause # 1 | The certificate profile in the system is identical to the CP/CPS | 2025-09-04 | Complete |
Appendix
Uploaded CSV file
|
|
Assignee | |
Comment 12•4 months ago
|
||
Report Closure Summary
Incident description
As part of a routine self-audit on August 6, 2025, an internal auditor discovered that one subscriber OV SSL certificate issued on May 27, 2025 included the emailAddress attribute in its Distinguished Name (DN). This attribute is not explicitly permitted by the subscriber certificate profile defined in the CP/CPS. The certificate was revoked the same day the issue was detected, and a full audit found no other certificates with the same non-compliance.
Incident Root Cause(s)
The root cause was a configuration drift between the certificate profile as implemented in the issuance system and the certificate profile as documented in the CP/CPS. The change control process at the time focused primarily on explicit modifications and did not include systematic validation against the CP/CPS, which allowed the drift to remain undetected.
Remediation description
The affected certificate was revoked in alignment with the CA/B Forum TLS Baseline Requirements. The issuance system configuration was updated to remove the non-permitted attribute. Additional validation checks were implemented to ensure strict alignment with the documented certificate profiles. Internal audit procedures were also enhanced to detect any future inconsistencies at an earlier stage.
Commitment summary
- Strengthen existing automated validation tools by adding further mechanisms to ensure certificate profile compliance prior to issuance.
- Staff training and refresher sessions to reinforce understanding of the CP/CPS permitted attributes, issuance profiles, and compliance requirements.
- Ongoing review and improvement of internal audit methodologies to strengthen early detection of non-compliances.
|
|
||
Comment 13•3 months ago
|
||
This is a final call for comments or questions on this Incident Report.
Otherwise, it will be closed on approximately 2025-09-26.
|
|
||
Updated•3 months ago
|
Description
•