2048995 - eMudhra emSign PKI Services: OCSP Responder Returned "Unauthorized" for Some Pecertificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Naveen Kumar ML]

Preliminary Incident Report

Summary

• Incident description: emSign CA served RFC 6960 unauthorized OCSP responses for three publicly logged precertificates for which the final certificates were not issued. These responses remained available beyond the 15-minute window required by BR §4.9.9 because OCSP status provisioning for failed issuance transactions was performed through a separate workflow that was not designed to complete within the required timeframe.
• Relevant policies: CA/Browser Forum TLS Baseline Requirements §4.9.9 (On-line revocation/status checking availability); RFC 6960 (Online Certificate Status Protocol) and Mozilla Root Store Policy Section 5.4: CA MUST provide CRL and OCSP services and responses for all certificates presumed to exist based on the presence of a pre-certificate, even if the certificate does not actually exist
• Source of incident disclosure: External report received via problem reporting, followed by internal review and analysis by the emSign PKI team.

Comment 1

[Naveen Kumar ML]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A005678

• Incident description: emSign CA served RFC 6960 "unauthorized" OCSP responses for three publicly logged precertificates for which final certificates were not issued. The "unauthorized" responses were served beyond the 15-minute window required by BR §4.9.9 because OCSP status provisioning for failed issuance transactions was performed through a separate internal workflow that was not designed to complete within the required timeframe. emSign's interpretation at the time was that BR §4.9.9 specifically prohibits serving the 'unknown' certificate status, and that 'unauthorized' — an RFC 6960 responder error response — was distinct from the prohibited 'unknown' status. Upon further internal review and analysis of BR §4.9.9 and RFC 6960, emSign concluded that this interpretation was not consistent with the intent of the requirement, which expects an authoritative OCSP response to be available within 15 minutes of a precertificate being publicly logged. emSign is filing this report as a matter of course correction.

• Timeline summary:

  • Non-compliance start date: June 3, 2026 at 16:17 UTC (earliest affected precertificate logged)
  • Non-compliance identified date: June 19, 2026 (following external notification and internal review of BR §4.9.9)
  • Non-compliance end date: June 11, 2026 at 03:40 UTC (all three precertificate records provisioned for OCSP); systemic fix implemented June 23, 2026

• Relevant policies:

  • CA/Browser Forum TLS Baseline Requirements §4.9.9 (On-line revocation/status checking availability)
  • RFC 6960 (Online Certificate Status Protocol)
  • Mozilla Root Store Policy Section 5.4 (Precertificates — CA MUST provide CRL and OCSP services and responses for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist)

• Source of incident disclosure: External report received via CCADB problem reporting, followed by internal review and analysis by the emSign PKI team.

Impact

• Total number of certificates: 3 precertificates

• Total number of "remaining valid" certificates: 0 (No final certificates were issued for any of the three affected precertificate entries; all affected precertificate records have since been provisioned for OCSP.)

• Affected certificate types: Precertificates only (CT poison extension present; technically invalid for TLS use)

• Incident heuristic: External report

• Was issuance stopped in response to this incident, and why or why not?: No. The incident relates to OCSP provisioning for failed issuance transactions and does not affect the certificate issuance process itself. No certificates were being incorrectly issued and therefore issuance was not stopped.

• Analysis: Three precertificates were publicly logged to Certificate Transparency logs as part of certificate issuance transactions that did not complete successfully. No final certificates were issued for any of these entries. The emSign OCSP provisioning process is tied to final certificate issuance; for precertificates where issuance did not complete, a separate internal workflow was responsible for provisioning OCSP status. This workflow was not designed to guarantee completion within the 15-minute window required by BR §4.9.9. OCSPWatch queried the OCSP responder for these serial numbers during the unprovisioned window and received "unauthorized" responses. The "unauthorized" response is an RFC 6960 error response and is not an authoritative OCSP status response as required by BR §4.9.9.

• Additional considerations: No subscribers were affected and no relying party certificate validation was impacted at any point. The precertificates carried a CT poison extension rendering them technically invalid for TLS use.

Timeline

Date/Time (UTC)	Event
June 3, 2026 at 16:17 UTC	Precertificate (Certspotter ID: 15196205645) logged to CT. Final certificate issuance did not complete. OCSP not provisioned. Non-compliance begins for this entry.
June 10, 2026 at 22:06 UTC	Precertificates (Certspotter IDs: 15322444056 and 15322444057) logged to CT. Final certificate issuance did not complete. OCSP not provisioned. Non-compliance begins for these two entries.
June 10, 2026 at 23:50 UTC	External notification received via CCADB problem reporting email reporting OCSPWatch errors for all three precertificate entries.
June 10–11, 2026	Upon receiving external notification, emSign PKI team reviewed the reported entries on OCSPWatch, identified the three affected precertificate records and initiated the internal workflow to provision OCSP status for all three serial numbers.
June 11, 2026 at 03:40 UTC	All three precertificate records processed through internal workflow. OCSP status provisioned for all three serial numbers. Non-compliance ends for these three specific entries.
June 11, 2026 at 05:03 UTC	emSign PKI team responded to reporter confirming the entries corresponded to precertificates with no final certificates issued and that the handling of these records had been updated.
June 12, 2026 at 01:12 UTC	Reporter responded requesting further explanation, citing Mozilla Root Store Policy Sections 5.2 and 5.4.
June 12, 2026 at 06:13 UTC	emSign PKI team responded providing additional technical context on the certificate issuance workflow and confirming no subscribers or relying parties were impacted.
June 15–19, 2026June 15, 2026 to June 19, 2026	emSign PKI team conducted detailed internal analysis of BR §4.9.9 language, RFC 6960 response types, and the distinction between 'unauthorized' and 'unknown' responses, including review of a related Bugzilla reference provided by the reporter. Further email exchange occurred between the reporter and emSign PKI team during this period. Following this analysis, emSign concluded on June 19 that the behavior constituted a compliance incident, as the interpretation that 'unauthorized' was permissible under BR §4.9.9 was not consistent with the intent of the requirement.
June 19, 2026 at 05:39 UTC	emSign PKI team responded to reporter acknowledging the interpretation gap, confirming the matter would be treated as a compliance incident, and committing to file an incident report, conduct a root cause analysis, and implement corrective actions.
June 19, 2026 at 17:26 UTC	Preliminary incident report submitted.
June 20, 2026 to June 22, 2026	Development and testing of updated workflow to provision OCSP status within 15 minutes of precertificate CT logging.
June 23, 2026 at 11:30 UTC	Updated workflow deployed to production. OCSP status now provisioned at precertificate logging stage rather than final certificate issuance stage. Systemic non-compliance ends..
June 25, 2026	Full incident report filed.

Related Incidents

Bug	Date	Description
Bug 1946927	February 8, 2025	Sectigo incident involving 'unauthorized' OCSP responses. Note: that incident involved fully issued final certificates where OCSP had been provisioned but was not being delivered due to a CDN replication failure. The emSign incident is distinct in that it involves precertificates only, for which final certificates were never issued.

Root Cause Analysis

Contributing Factor 1: OCSP Provisioning Tied to Final Certificate Issuance

• Description:: emSign's OCSP provisioning process was designed to activate certificate status information upon successful final certificate issuance. For precertificates where final issuance did not complete, OCSP status was not provisioned at the point of CT logging, resulting in 'unauthorized' responses being served beyond the 15-minute window required by BR §4.9.9.

• Timeline: This design has been in place since the implementation of the OCSP provisioning process. The BR §4.9.9 15-minute requirement became effective January 15, 2025.

• Detection: Identified through external notification and subsequent internal review: Identified through external notification via CCADB problem reporting and subsequent internal review of BR §4.9.9.

• Interaction with other factors: Combined with Contributing Factor 2, this resulted in 'unauthorized' responses being served for an extended period for precertificates from failed issuance transactions..

• Root Cause Analysis methodology used: Internal review and timeline analysis.

Contributing Factor 2: Internal Workflow Not Designed for 15-Minute Compliance

• Description: : A separate internal workflow was responsible for provisioning OCSP status for precertificates from failed issuance transactions. This workflow was not designed to guarantee completion within the 15-minute window required by BR §4.9.9. The workflow operated as a periodic process rather than a real-time provisioning mechanism.

• Timeline: Precertificate 15196205645 logged June 3, 2026 — provisioned June 11, 2026 (approximately 7 days 11 hours). Precertificates 15322444056 and 15322444057 logged June 10, 2026 — provisioned June 11, 2026 (approximately 5.5 hours).

• Detection: Identified through external notification via CCADB problem reporting and subsequent internal review.

• Interaction with other factors: Combined with Contributing Factor 1, the delayed provisioning resulted in extended periods of non-compliant OCSP responses.

• Root Cause Analysis methodology used: Internal review and timeline analysis.

Contributing Factor 3: Interpretation of BR §4.9.9 "unknown" Prohibition

• Description: BR §4.9.9 states that an authoritative OCSP response MUST be available, specifically noting the responder MUST NOT respond with the 'unknown' status. emSign interpreted this as prohibiting the 'unknown' certificate status response while permitting the RFC 6960 'unauthorized' responder error for serials that had not yet been provisioned through the internal workflow. Upon internal review, emSign concluded this interpretation was not consistent with the intent of the requirement, which expects any publicly logged precertificate serial to receive an authoritative OCSP response within 15 minutes of CT logging regardless of whether final certificate issuance completes. emSign is filing this report as a matter of course correction based on this revised interpretation.

• Timeline: This interpretation was in place from the time the internal workflow was implemented.

• Detection: This interpretation contributed to the delayed identification of the compliance gap, as the team initially assessed the behavior as operationally acceptable based on the reading of the 'unknown' prohibition.

• Interaction with other factors: Delayed identification of the compliance gap.

• Root Cause Analysis methodology used: Internal review of BR §4.9.9 language and RFC 6960 response type requirements.

Lessons Learned

• What went well: The CCADB external problem reporting mechanism functioned as intended. Internal review of BR §4.9.9 successfully identified the compliance gap. All three affected precertificate records were remediated and OCSP status was made available promptly upon receiving the external notification. No final certificates were issued and no subscribers or relying parties were impacted.

• What didn’t go well: The internal workflow for provisioning OCSP status for failed issuance transactions was not designed with the 15-minute BR §4.9.9 requirement in mind. The interpretation of BR §4.9.9's 'unknown' prohibition was not assessed against the broader intent of the requirement at the time of implementation, which delayed the identification of the compliance gap.

• Where we got lucky: : No final certificates were issued for any of the three affected precertificate entries. The precertificates carried a CT poison extension rendering them technically invalid for TLS use. No subscribers were affected and no relying party certificate validation was impacted at any point.

• Additional: N/A

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Provision OCSP status at precertificate logging stage rather than final certificate issuance	Prevent	Contributing Factor 1 & 3	OCSP status available within 15 minutes of CT logging for all precertificates including failed issuances	24-06-2026	Completed
Update internal workflow to guarantee OCSP provisioning within 15-minute window for failed issuance transactions	Prevent	Contributing Factor 2 & 3	No precertificate from a failed issuance transaction remains unprovisioned beyond 15 minutes of CT logging	24-06-2026	Completed
Update CP/CPS to document OCSP provisioning process and SLA for precertificates including failed issuance transactions	Prevent	Contributing Factors 1, 2	CP/CPS updated and published	15-07-2026	In Progress

Appendix

Certificate details are enclosed

Comment 2

[Naveen Kumar ML]

Attachment: Certificate_List_OCSP_PreCert.xlsx

Comment 3

[Naveen Kumar ML]

We are working on the action item and we will provide the update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Provision OCSP status at precertificate logging stage rather than final certificate issuance	Prevent	Contributing Factor 1	OCSP status available within 15 minutes of CT logging for all precertificates including failed issuances	24-06-2026	Completed
Update internal workflow to guarantee OCSP provisioning within 15-minute window for failed issuance transactions	Prevent	Contributing Factor 2	No precertificate from a failed issuance transaction remains unprovisioned beyond 15 minutes of CT logging	24-06-2026	Completed
Update CP/CPS to document OCSP provisioning process and SLA for precertificates including failed issuance transactions	Prevent	Contributing Factors 1, 2	CP/CPS updated and published	15-07-2026	In Progress

Comment 4

[Ophelia P.]

Adding for transparency, as the external reporter of this issue.

1. emSign was aware of the core behavior from the moment my report arrived on June 10, 2026 at 23:50 UTC: their OCSP responder was returning 'unauthorized' for publicly logged precertificates. emSign's first response dismissed the issue as limited to precertificates with no relying-party impact. Their second response provided additional technical context but still did not acknowledge a violation. It was only after I cited Mozilla Root Store Policy §5.4, asked twice for SLA and per-certificate timing information that went unanswered, and separately cited Bug #1946927 that emSign concluded on June 19 that this constituted a compliance incident. That is nine days after external notification and three rounds of escalating follow-up. This is itself a process failure that the incident report does not acknowledge. The capacity to recognize a compliance incident should not depend on a reporter progressively educating the CA through a chain of emails.

2. The CCADB Incident Reporting Guidelines require disclosure within 72 hours of a CA "becoming aware of an incident" - not within 72 hours of formally determining that a violation occurred. emSign was aware of the behavior on June 10, 2026 at 23:50 UTC: their OCSP responder was returning 'unauthorized' responses for publicly logged precertificates. Awareness of that behavior is what starts the clock, not the conclusion of an internal investigation into whether it constitutes a violation. Bug #1963629 (HARICA) demonstrates the correct approach: HARICA filed a preliminary report explicitly stating they were "not 100% certain if this is a violation" and sought community guidance. emSign, holding all relevant facts and having received an external report citing specific policy provisions, had at minimum the same obligation to file promptly and investigate concurrently. The preliminary report was filed June 19, 2026 at 17:26 UTC, approximately 210 hours after external notification. Please explain why a preliminary report for transparency was not filed within 72 hours of June 10, regardless of whether the compliance characterization had been finalized.

3. The report cites Bug #1946927 (Sectigo, February 2025) and distinguishes it on technical grounds: different root cause, different certificate class. That distinction is accurate but misses the critical point. Sectigo's incident report contains the following explicit statement: "Only signed 'good' and 'revoked' OCSP responses are compliant with this requirement, which means that unsigned 'unauthorized' OCSP responses are not." This sentence, published in a publicly available community incident report in February 2025, directly resolves the interpretive question emSign describes in Contributing Factor 3, the belief that 'unauthorized' was distinct from the prohibited 'unknown' and therefore permissible. That interpretation had been explicitly addressed in the community record nearly sixteen months before emSign's non-compliance began on June 3, 2026. emSign either did not read this report, read it but did not apply its conclusions to their own architecture, or read it and failed to act. None of those explanations is reassuring for a CA that is expected to actively monitor community precedents as part of its compliance obligations. Please explain what process emSign uses to monitor and apply lessons from community incident reports, and why this precedent was not identified and applied when the BR §4.9.9 15-minute requirement took effect on January 15, 2025.

4. Precertificate 15196205645 was logged June 3, 2026 at 16:17 UTC and provisioned June 11, 2026 at 03:40 UTC, representing approximately 179 hours of non-compliance against a 15-minute requirement. This is the most significant data point in the timeline and is understated in the report's summary. Please confirm this calculation is accurate and address it directly.

5. The report covers three externally-reported entries and treats those three as the complete scope of impact. The root cause, however, was a periodic internal workflow not designed to provision OCSP status within 15 minutes for failed issuance transactions, and it was in place from at least the January 15, 2025 effective date of BR §4.9.9 through June 23, 2026 when the systemic fix was deployed. The three certificates I reported were discovered externally; there is no basis in the report to conclude they were the only affected entries. Please provide the exact number of failed issuance transactions between January 15, 2025 and June 23, 2026 where OCSP status provisioning exceeded the 15-minute requirement, not limited to the three externally discovered entries, but derived from a complete query of emSign's issuance and OCSP provisioning records. Additionally, please confirm whether any failed issuance transactions between June 11 and June 23 were subject to the same non-compliant behavior during the window between individual remediation and systemic fix deployment.

6. I asked on June 16 and again on June 18 whether the SLA for the internal OCSP provisioning workflow was documented in emSign's CPS. Neither question was answered in the email exchange. The CP/CPS update action item due July 15 implicitly confirms there is currently no documented SLA. Please confirm this, and confirm that the July 15 update will include a specific, measurable SLA rather than a general process description.

7. The behavior documented in this report raises questions about the depth and accessibility of emSign's compliance expertise and the effectiveness of its internal escalation path from CPR receipt to compliance review: a front-line team that initially dismissed a clear policy violation, required multiple rounds of external escalation before a compliance determination was made, and was unfamiliar with a directly relevant community precedent published more than a year earlier. What is the escalation path from initial CPR receipt to a compliance-qualified reviewer, how many steps does it involve, and what assurance exists that reports describing potential policy violations are routed to someone with the technical and regulatory knowledge to evaluate them? The email exchange associated with this report suggests that path is either long, unclear, or insufficiently staffed.

Comment 5

[Naveen Kumar ML]

(In reply to Ophelia P. from comment #4)

Adding for transparency, as the external reporter of this issue.

1. emSign was aware of the core behavior from the moment my report arrived on June 10, 2026 at 23:50 UTC: their OCSP responder was returning 'unauthorized' for publicly logged precertificates. emSign's first response dismissed the issue as limited to precertificates with no relying-party impact. Their second response provided additional technical context but still did not acknowledge a violation. It was only after I cited Mozilla Root Store Policy §5.4, asked twice for SLA and per-certificate timing information that went unanswered, and separately cited Bug #1946927 that emSign concluded on June 19 that this constituted a compliance incident. That is nine days after external notification and three rounds of escalating follow-up. This is itself a process failure that the incident report does not acknowledge. The capacity to recognize a compliance incident should not depend on a reporter progressively educating the CA through a chain of emails.

Our initial assessment treated the reported entries as precertificates from incomplete issuance transactions for which no final certificates were issued and no subscribers or relying parties were affected, and on that basis the matter was not initially characterized as a compliance incident. As the exchange developed, we reviewed BR §4.9.9, Mozilla Root Store Policy Section 5.4, and RFC 6960 together, and considering the overall objective of those requirements when read as a whole, we concluded on June 19, 2026 that the responder behavior was not compliant and that the matter constituted a compliance incident.
We acknowledge that the compliance dimension should have been identified earlier in our review rather than later in the exchange. As described in point 7, we have revised our process so that any CPR relating to OCSP, revocation, CT logging, or certificate status is routed to compliance-qualified reviewers immediately upon receipt, in parallel with the technical investigation, so that the compliance implications of such reports are evaluated from the outset.

2. The CCADB Incident Reporting Guidelines require disclosure within 72 hours of a CA "becoming aware of an incident" - not within 72 hours of formally determining that a violation occurred. emSign was aware of the behavior on June 10, 2026 at 23:50 UTC: their OCSP responder was returning 'unauthorized' responses for publicly logged precertificates. Awareness of that behavior is what starts the clock, not the conclusion of an internal investigation into whether it constitutes a violation. Bug #1963629 (HARICA) demonstrates the correct approach: HARICA filed a preliminary report explicitly stating they were "not 100% certain if this is a violation" and sought community guidance. emSign, holding all relevant facts and having received an external report citing specific policy provisions, had at minimum the same obligation to file promptly and investigate concurrently. The preliminary report was filed June 19, 2026 at 17:26 UTC, approximately 210 hours after external notification. Please explain why a preliminary report for transparency was not filed within 72 hours of June 10, regardless of whether the compliance characterization had been finalized.

The preliminary incident report was filed on June 19, 2026 at 17:26 UTC. Upon receiving the external notification on June 10, 2026 at 23:50 UTC, our team responded within approximately five hours and remained continuously engaged with the reporter, responding on June 11, June 12, June 17, and June 19.
Upon initial review, our assessment was based on the specific language of BR §4.9.9, which states that the responder must not respond with the "unknown" status. On the basis of that assessment, and given that the reported entries related to precertificates from incomplete issuance transactions for which no final certificates were issued and no subscribers or relying parties were affected, the matter was not initially characterized as a compliance incident. Through the subsequent exchange, and after reviewing BR §4.9.9, Mozilla Root Store Policy Section 5.4, and RFC 6960 together, and considering the overall objective of those requirements when read as a whole, we concluded on June 19, 2026 that the responder behavior was not compliant and that the matter constituted a compliance incident. A preliminary incident report was filed immediately upon reaching that conclusion.
While we recognize that there can be a distinction between awareness of a technical behavior and the determination that it constitutes a compliance incident, we accept that the more prudent approach is to file a preliminary incident report promptly while the compliance assessment proceeds in parallel. We have therefore revised our internal process to adopt this approach going forward, as described in point 7.

3. The report cites Bug #1946927 (Sectigo, February 2025) and distinguishes it on technical grounds: different root cause, different certificate class. That distinction is accurate but misses the critical point. Sectigo's incident report contains the following explicit statement: "Only signed 'good' and 'revoked' OCSP responses are compliant with this requirement, which means that unsigned 'unauthorized' OCSP responses are not." This sentence, published in a publicly available community incident report in February 2025, directly resolves the interpretive question emSign describes in Contributing Factor 3, the belief that 'unauthorized' was distinct from the prohibited 'unknown' and therefore permissible. That interpretation had been explicitly addressed in the community record nearly sixteen months before emSign's non-compliance began on June 3, 2026. emSign either did not read this report, read it but did not apply its conclusions to their own architecture, or read it and failed to act. None of those explanations is reassuring for a CA that is expected to actively monitor community precedents as part of its compliance obligations. Please explain what process emSign uses to monitor and apply lessons from community incident reports, and why this precedent was not identified and applied when the BR §4.9.9 15-minute requirement took effect on January 15, 2025.

Our interpretation at the relevant time was based on the specific language of BR §4.9.9, which states that the responder must not respond with the "unknown" status. On that basis, we initially assessed that the RFC 6960 responder-level "unauthorized" response was distinct from the prohibited certificate status of "unknown." This assessment was reviewed internally, including by a policy authority member.
We have since reviewed Bug #1946927. That incident concerned fully issued final certificates for which OCSP responses had been provisioned but were temporarily unavailable due to a CDN replication failure. The certificate class, root cause, and failure mode differ materially from the present incident, which concerns precertificates from incomplete issuance transactions for which no final certificates were issued.
While Bug #1946927 is not itself a normative source, it highlighted an interpretation that we should have evaluated against our own implementation once the BR §4.9.9 requirement became effective. Through our subsequent review of the Baseline Requirements, Mozilla Root Store Policy, and RFC 6960 together, and considering the overall objective of those requirements when read as a whole, we concluded that the general principle regarding acceptable OCSP responder behavior applies equally in our scenario and that our initial interpretation was not the correct one.
To strengthen future policy assessments, we are implementing a structured periodic review of community incident reports relevant to our issuance, revocation, CT logging, and OCSP architecture so that applicable principles identified by the community are systematically evaluated against our own implementation.

4. Precertificate 15196205645 was logged June 3, 2026 at 16:17 UTC and provisioned June 11, 2026 at 03:40 UTC, representing approximately 179 hours of non-compliance against a 15-minute requirement. This is the most significant data point in the timeline and is understated in the report's summary. Please confirm this calculation is accurate and address it directly.

We confirm the calculation. Precertificate 15196205645 was logged on June 3, 2026 at 16:17 UTC and OCSP status was made available on June 11, 2026 at 03:40 UTC, a period of approximately 179 hours and 23 minutes. This period was disclosed in the timeline of the incident report.
Throughout this period, no final certificate corresponding to this precertificate was issued, and therefore no subscriber or relying party relied upon a certificate for this serial. This statement is intended solely to characterize the actual impact and not to diminish the duration of the non-compliance, which we confirm as stated.

5. The report covers three externally-reported entries and treats those three as the complete scope of impact. The root cause, however, was a periodic internal workflow not designed to provision OCSP status within 15 minutes for failed issuance transactions, and it was in place from at least the January 15, 2025 effective date of BR §4.9.9 through June 23, 2026 when the systemic fix was deployed. The three certificates I reported were discovered externally; there is no basis in the report to conclude they were the only affected entries. Please provide the exact number of failed issuance transactions between January 15, 2025 and June 23, 2026 where OCSP status provisioning exceeded the 15-minute requirement, not limited to the three externally discovered entries, but derived from a complete query of emSign's issuance and OCSP provisioning records. Additionally, please confirm whether any failed issuance transactions between June 11 and June 23 were subject to the same non-compliant behavior during the window between individual remediation and systemic fix deployment.

Our investigation to date has determined that all final certificates issued during the review period had OCSP responses provisioned as required. The behavior identified in this incident appears to be limited to precertificates for which the corresponding final certificates were never issued.
As noted in our earlier response, in such cases OCSP status is made available through an internal mechanism. The gap arose specifically where inconsistencies in database flags prevented OCSP status from being made available for these records as expected, resulting in delayed OCSP provisioning for the reported precertificates.
We acknowledge that the three externally reported entries should not be assumed to represent the complete scope, as they were identified by the reporter through OCSPWatch rather than through our own detection mechanisms. Accordingly, we have initiated a comprehensive review of our issuance and OCSP records covering the period from January 15, 2025 through June 23, 2026. This review includes all failed issuance transactions where precertificates were publicly logged, final certificates were not issued, and OCSP status may not have been made available within the 15-minute requirement due to the same database flag inconsistency.
Our investigation to date indicates that the behavior was limited to precertificates for which the corresponding final certificates were never issued. The ongoing review is intended to verify that assessment, identify any additional affected records, and specifically examine the period from June 11 through June 23, 2026 between remediation of the reported entries and deployment of the systemic fix.
We will provide the complete results of this review, including the total number of affected precertificates, within seven days.

6. I asked on June 16 and again on June 18 whether the SLA for the internal OCSP provisioning workflow was documented in emSign's CPS. Neither question was answered in the email exchange. The CP/CPS update action item due July 15 implicitly confirms there is currently no documented SLA. Please confirm this, and confirm that the July 15 update will include a specific, measurable SLA rather than a general process description.

We confirm that our CP/CPS did not document a specific operational SLA governing OCSP availability for failed issuance transactions. The CP/CPS update scheduled for July 15, 2026 will include a specific, measurable operational requirement aligned with the 15-minute availability requirement of BR §4.9.9.

7. The behavior documented in this report raises questions about the depth and accessibility of emSign's compliance expertise and the effectiveness of its internal escalation path from CPR receipt to compliance review: a front-line team that initially dismissed a clear policy violation, required multiple rounds of external escalation before a compliance determination was made, and was unfamiliar with a directly relevant community precedent published more than a year earlier. What is the escalation path from initial CPR receipt to a compliance-qualified reviewer, how many steps does it involve, and what assurance exists that reports describing potential policy violations are routed to someone with the technical and regulatory knowledge to evaluate them? The email exchange associated with this report suggests that path is either long, unclear, or insufficiently staffed.

Our CPR handling process comprises:

1. Receipt and review by the technical PKI team.
2. Technical assessment of the reported behavior.
3. Escalation to the compliance team where a compliance dimension is identified.
4. Compliance review against the Baseline Requirements, Mozilla Root Store Policy, RFC requirements, and other applicable program requirements.
5. Escalation to policy authority members where policy interpretation is required.

The process is staffed at each stage by personnel with the relevant technical and regulatory expertise, and a policy authority member participated in the assessment of this matter.
In this instance, the compliance dimension was not identified during the initial assessment as promptly as it should have been. The process included both technical and policy authority review; however, the compliance review should have been initiated earlier in parallel with the technical assessment.
We have therefore revised our process so that any CPR relating to OCSP, revocation, CT logging, certificate status, or comparable compliance-sensitive topics is automatically routed to compliance-qualified reviewers immediately upon receipt, in parallel with the technical investigation. This ensures that potential compliance implications are evaluated from the outset while technical investigation proceeds concurrently.
We do not believe the issue arose from insufficient staffing or lack of policy expertise. Rather, it arose from the timing of the compliance review within the escalation workflow, and that workflow has now been revised accordingly.

We will provide a further update within seven days covering the results of the complete database review, the analysis of the June 11 to June 23, 2026 period, and the final count of all affected precertificates identified through that review.

Comment 6

[Naveen Kumar ML]

Further to our previous response, we are providing the results of the complete review of our issuance and OCSP records covering the period from January 15, 2025 through June 23, 2026.

The review identified 81 precertificates for the period from January 15, 2025 through June 11, 2026 and OCSP status was not made available within the 15-minute requirement. For all of these entries, only the precertificate exists and no corresponding final certificate was issued. OCSP status information has since been made available for all of these entries. Final certificates issued during this period were not affected.

Regarding the period from June 11 through June 23, 2026, between the remediation of the three reported entries and the deployment of the systemic fix, the review identified 7 precertificates from failed issuance transactions. For these entries, OCSP status was made available within the 15-minute requirement. Accordingly, these entries were not subject to the non-compliant behavior described in this incident.

The systemic fix deployed on June 23, 2026 provisions OCSP status at the precertificate logging stage, ensuring authoritative OCSP status is available within the 15-minute requirement for all precertificates going forward, including those from failed issuance transactions. Our CP/CPS has also been updated and published to document this requirement, aligned with the CA/Browser Forum TLS Baseline Requirements.

Status Update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Provision OCSP status at precertificate logging stage rather than final certificate issuance	Prevent	Contributing Factor 1	OCSP status available within 15 minutes of CT logging for all precertificates including failed issuances	24-06-2026	Complete
Update internal workflow to guarantee OCSP provisioning within 15-minute window for failed issuance transactions	Prevent	Contributing Factor 2	No precertificate from a failed issuance transaction remains unprovisioned beyond 15 minutes of CT logging	24-06-2026	Complete
Update CP/CPS to document OCSP provisioning process and SLA for precertificates including failed issuance transactions	Prevent	Contributing Factors 1, 2	CP/CPS updated and published	15-07-2026	Complete

Comment 7

[Naveen Kumar ML]

Report Closure Summary

• Incident description: emSign CA served RFC 6960 "unauthorized" OCSP responses for publicly logged precertificates for which the corresponding final certificates were not issued. These "unauthorized" responses, which are not authoritative OCSP responses under BR §4.9.9, were served beyond the 15-minute availability requirement. The behavior was limited to precertificates from incomplete issuance transactions; final certificates issued during the review period had OCSP responses provisioned as required and were not affected. A complete review of issuance and OCSP records from January 15, 2025 through June 23, 2026 identified 81 precertificates (January 15, 2025 through June 11, 2026) for which OCSP status was not made available within the 15-minute requirement. For the period from June 11 through June 23, 2026, 7 precertificates from failed issuance transactions were identified, all of which had OCSP status made available within the 15-minute requirement and were therefore not subject to the non-compliant behavior.
• Incident Root Cause(s): OCSP status provisioning was tied to final certificate issuance. For precertificates where the final certificate was not issued, OCSP status was made available through a separate internal mechanism involving automated and manual steps. This mechanism did not consistently make OCSP status available within the 15-minute window required by BR §4.9.9. In addition, the escalation of the report for compliance review occurred later in the process than intended, which is addressed by the revised CPR handling process described below.
• Remediation description: OCSP status is now provisioned at the precertificate logging stage rather than at final certificate issuance, ensuring authoritative OCSP status is available within the 15-minute requirement for all precertificates, including those from failed issuance transactions. The systemic fix was deployed on June 23, 2026. All affected precertificates identified through the complete records review have had OCSP status made available. The CP/CPS has been updated and published to document the 15-minute availability requirement. The internal CPR handling process has been revised so that reports relating to OCSP, revocation, CT logging, or certificate status are routed to compliance-qualified reviewers immediately upon receipt, in parallel with the technical investigation. The structured periodic review of community incident reports relevant to our issuance, revocation, CT logging, and OCSP architecture has been implemented.
• Commitment summary: emSign has provisioned OCSP status for all affected precertificates, deployed a systemic fix ensuring OCSP availability within the 15-minute requirement for all precertificates, published the corresponding CP/CPS update, revised its CPR escalation process, and implemented a structured periodic review of community incident reports.

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

Comment 8

[incident-reporting]

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

Otherwise, it will be closed on approximately 2026-07-30.