2016722 - PostSignum: Mis-issued certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[CA PostSignum]

Steps to reproduce:

Preliminary Incident Report
Summary
Incident description: One TLS Mis-issuance in a CA environment by a fictitious data
Relevant policies: PostSignum CA Certificate Policy for Commercial TLS certificates v.5.0.4 Chapter 9.17
Source of incident disclosure: CA operator - Self reported

Comment 1

[CA PostSignum]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000259
• Incident description: After a service intervention, the CA operator performed a functionality test of the CA service – PostSignum Public CA 5 for certificate issuance. Due to an error by the CA operator, the certification policy (CP) was mistakenly selected during the issuance of a test certificate. Instead of the test CP, the operational CP for TLS certificates was chosen. According to the TLS policy it is prohibited to issue any test certificates.

For testing purposes, fictitious data are used (commonName=test.tt, organizationName=test, organizationIdentifier=NTRCZ-12345678, DNS=test.tt). The same data were mistakenly entered under the operational CP. This was a human error on the part of the CA operator, who holds the highest privileges for CA management at the CA core level.

https://crt.sh/?id=24306471323

There was no issue at the Registration Authority level and no compromise of the registration process occurred. The key for issuing the certificate was generated directly in the authority. A control mechanism functioned as intended – certificates issued directly from the CA core are reviewed by another CA operator, who detected the incorrectly issued certificate and initiated its revocation.

• Timeline summary:

  • Non-compliance start date:
    10.02.2026 09:26 (UTC)
  • Non-compliance identified date:
    10.02.2026 09:45 (UTC)
  • Non-compliance end date:
    10.02.2026 10:04 (UTC)

• Relevant policies:
  PostSignum CA Certificate Policy for Commercial TLS certificates v.5.0.4 (https://www.postsignum.cz/files/politiky/VCA_ssl_crt_v5-0-4_eng.pdf), Chapter 8.5, CCADB Incident Report

• Source of incident disclosure:
  CA operator - Self reported

Impact

• Total number of certificates:
  The total number of affected certificates is 1.

• Total number of "remaining valid" certificates:
  There are no "remaining valid" certificates.

• Affected certificate types:
  This incident affects OV certificate issued for non validated data by CA Operator.

• Incident heuristic:
  This incident affected 1 certificate issued 10.02.2026 09:26 (UTC).

• Was issuance stopped in response to this incident, and why or why not?:
  No, we did not stop issuing because a service operation failed not because of a process failure.

Timeline

10.02.2026 09:10 (UTC) – Service intervention performed by CA operator.

10.02.2026 09:26 (UTC) – CA service functionality test performed by issuing a test certificate by CA operator.

10.02.2026 09:30 (UTC) – Information about certificate issuance from CA core.

10.02.2026 09:45 (UTC) – Issued certificate reviewed by second CA operator.

10.02.2026 09:50 (UTC) – Identification of incorrect CP used for issuing the test certificate.

10.02.2026 09:55 (UTC) – Decision to revoke the certificate.

10.02.2026 10:04 (UTC) – Certificate revoked.

10.02.2026 12:00 (UTC) – Steps initiated to collect information for incident registration.

10.02.2026 12:15 (UTC) - Temporary stop the issuing of certificates for internal testing.

11.02.2026 9:00 (UTC) - The meeting was called to prepare the training of CA operators and the report.

11.02.2026 13:00 (UTC) - Internal documentation was modified.

12.02.2026 10:00 (UTC) - Training employees on requirements and procedures for issuing test certificates.

13.02.2026 16:00 (UTC) - Preliminary Incident Report has been published Bugzilla.

16.02.2026 - 9:00 (UTC) - The information in the TLS operational policy and test policy has been modified in CA core.

19.02.2026 13:35 (UTC) - The External Audit body has been informed.

Related Incidents

N/A

Root Cause Analysis

Contributing Factor 1: Incompletely process of issuing testing certificates

• Description: Incorrectly undefined data for issuing test certificates. In the internal documentation, the CA testing process has been expanded to include real data that should always be used for testing. The data is no longer fictitious, but corresponds to reality. Service test certificates are by default non-public and have no impact on the CT log, and their issuance is described in internal documentation. Only specially trained employees have access to CA core, this is a narrow group with special rights.
• Detection:
  The issue was identified by analyzing the certificates by the CA review operator.
• Interaction with other factors:
  N/A
• Root Cause Analysis methodology used:
  Review of CA core releases and timeline reconstruction.

Lessons Learned

• What went well:
  The control mechanism worked and affected certificate was revoked in a timely manner.
• What didn’t go well:
  Relevant data for the test certificate has not been defined. The wrong policy was selected for selecting the test certificate.
• Where we got lucky:
  The domain used is not registered.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Editing internal documentation	Prevent	Root Cause # 1	Before the operator training, the description of the issuance of test certificates in the internal documentation was modified. The data that must be used to issue the test certificate was added. This data cannot be edited.	2026-02-11	Completed
Employee training on requirements and procedures for issuing test certificates	Prevent	Root Cause # 1	CA operators were instructed on the need for increased caution when working in the CA core environment. Release procedures, the essentials of their role were reviewed, and new measures were consulted.	2026-02-12	Completed
CA core modification	Prevent	Root Cause # 1	1) Fixed dates for issuing a test certificate have been added and cannot be modified. 2) The operational policy for issuing TLS has been marked with a visible warning that contains a prohibition on use for a test certificate.	2026-02-16	Completed

Comment 2

[Dimitris Zacharopoulos]

If you take a closer look at https://wiki.mozilla.org/CA/Closed_Incidents you will find several incidents with similar topic (using dummy or non-validated data in production certificates). These should be carefully reviewed and added to the "Related Incidents" section.

Comment 3

[Martijn Katerbarg]

Source of incident disclosure: CA operator - Self reported

Timeline

This timeline appears to be missing an entry where a Certificate Problem Report was received for the certificate in question. That seems relevant to this incident.

In addition to that, can you expand on if any QA systems are interconnected with your production systems?

It seems like this certificate was meant to be issued as a test, I am puzzled as to why this would be done through a system connected to a production CA.

Comment 4

[CA PostSignum]

(In reply to Dimitris Zacharopoulos from comment #2)

If you take a closer look at https://wiki.mozilla.org/CA/Closed_Incidents you will find several incidents with similar topic (using dummy or non-validated data in production certificates). These should be carefully reviewed and added to the "Related Incidents" section.

Thanks Dimitris, we thought it was just our own "Related Incidents" section. We will add them based on the carefully review as you suggest.

Comment 5

[CA PostSignum]

(In reply to Martijn Katerbarg from comment #3)

Source of incident disclosure: CA operator - Self reported

Timeline

This timeline appears to be missing an entry where a Certificate Problem Report was received for the certificate in question. That seems relevant to this incident.

In addition to that, can you expand on if any QA systems are interconnected with your production systems?

It seems like this certificate was meant to be issued as a test, I am puzzled as to why this would be done through a system connected to a production CA.

Q1) Thank you for the notice, added.
Q2) Yes, the authority is connected to QA, but not to one that would prevent this error.
Q3) Yes, it should have been tested as part of testing the production certification authority.

Timeline

10.02.2026 09:10 (UTC) – Service intervention performed by CA operator.

10.02.2026 09:26 (UTC) – CA service functionality test performed by issuing a test certificate by CA operator.

10.02.2026 09:30 (UTC) – Information about certificate issuance from CA core.

10.02.2026 09:45 (UTC) – Issued certificate reviewed by second CA operator.

10.02.2026 09:50 (UTC) – Identification of incorrect CP used for issuing the test certificate.

10.02.2026 09:55 (UTC) – Decision to revoke the certificate.

10.02.2026 10:04 (UTC) – Certificate revoked.

10.02.2026 12:00 (UTC) – Steps initiated to collect information for incident registration.

10.02.2026 12:15 (UTC) - Temporary stop the issuing of certificates for internal testing.

11.02.2026 9:00 (UTC) - The meeting was called to prepare the training of CA operators and the report.

11.02.2026 13:00 (UTC) - Internal documentation was modified.

12.02.2026 10:00 (UTC) - Training employees on requirements and procedures for issuing test certificates.

12.02.2026 12:51 (UTC) - Received Certificate Problem Report from a third party.

13.02.2026 16:00 (UTC) - Preliminary Incident Report has been published Bugzilla.

16.02.2026 - 9:00 (UTC) - The information in the TLS operational policy and test policy has been modified in CA core.

19.02.2026 13:35 (UTC) - The External Audit body has been informed.

Comment 6

[CA PostSignum]

Related Incidents

We have reviewed dozens of related incidents and here are some that have been resolved over a period of approximately two-year period:

Bug	Date	Description
1876871	2024-01-26	A test certificate was issued on a production system.
1859694	2023-10-17	Fast incident detection and reporting, misissued test certificates.

Comment 7

[Andrew Ayer]

As I understand it, the "CA core" permits operators to issue publicly-trusted certificates bypassing domain validation.

1. How many operators have access to the CA core?
2. Under what circumstances are operators permitted to access the CA core?
3. How often do operators access the CA core?
4. Why are certificates issued from the CA core only reviewed after the fact, instead of prior to issuance?

Comment 8

[CA PostSignum]

(In reply to Andrew Ayer from comment #7)

As I understand it, the "CA core" permits operators to issue publicly-trusted certificates bypassing domain validation.

No, certificates are not allowed to be issued from the core CA.

1. How many operators have access to the CA core?

There are three operators in total who have access.

2. Under what circumstances are operators permitted to access the CA core?

Physical access only, accompanied by the CA Administrator, and only in justified cases.

3. How often do operators access the CA core?

Since January 2025, they have accessed twice.

4. Why are certificates issued from the CA core only reviewed after the fact, instead of prior to issuance?

The CA core is not allowed to issue TLS certificates, the certificate data is checked by the registration authority.

Comment 9

[Andrew Ayer]

In Comment 1, you described an incident in which a publicly-trusted TLS server certificate was "issued directly from the CA core" without domain validation being performed. How is that consistent with your answers in Comment 8?

Comment 10

[CA PostSignum]

(In reply to Andrew Ayer from comment #9)

In Comment 1, you described an incident in which a publicly-trusted TLS server certificate was "issued directly from the CA core" without domain validation being performed. How is that consistent with your answers in Comment 8?

I apologize and I would like to clarify the given answer. Technically a CA operator can issue any certificate from a core CA, but a CA operator must only issue a test certificate. The core CA does not verify any registration data. Registration data are always verified by the registration authority, which, after verification, forwards the issuance requests to the core CA. The CA operator is not permited to issue a TLS certificate.

Comment 11

[Andrew Ayer]

Thanks for the clarification. As this incident shows, just because a CA operator is not supposed to do something, doesn't mean they can't do it. Many past incidents have explained why blaming "human error" and responding with more training is rarely an adequate response. I would encourage you to come up with additional technical measures to avoid a recurrence of this incident. For example, it would appear that testing is currently an acceptable justification for accessing the CA core. Is there are a way to enable testing that doesn't require accessing the CA core?

Comment 12

[CA PostSignum]

(In reply to Andrew Ayer from comment #11)

Thanks for the clarification. As this incident shows, just because a CA operator is not supposed to do something, doesn't mean they can't do it. Many past incidents have explained why blaming "human error" and responding with more training is rarely an adequate response. I would encourage you to come up with additional technical measures to avoid a recurrence of this incident. For example, it would appear that testing is currently an acceptable justification for accessing the CA core. Is there are a way to enable testing that doesn't require accessing the CA core?

It is technically not possible to prevent the CA operator from issuing any certificate in the core CA. The CA operator is the person with the highest authority and as such can change the core CA configuration including all certification policies. As a standard, production system tests are already performed at the registration authority level, where it is technically impossible to issue a TLS certificate with fictitious data, this is secured. We have implemented measures to prevent the recurrence of such errors in the future. We take the situation very seriously and recognize that all operations must be built on a resilient automated process that eliminates human intervention.

Comment 13

[CA PostSignum]

Report Closure Summary

• Incident description:
  After the service intervention there was a certificate mississued from the CA core with unverified data.
• Incident Root Cause(s):
  #1 Mis-issue of the certificate directly from the CA core due to insufficient definition of the data to be used for tests.
• Remediation description: Steps performed -
  ○ The mis-issued certificate was revocated.
  ○ New internal procedures were established.
  ○ Employees were trained in the newly set procedures for testing certificates when working with CA core.
  ○ Adjustment of CA core issuance - adding data for issuing testing certificates, which were properly marked and which cannot be modified.
• Commitment summary:
  All remediations are complete, with no outstanding actions. We have completed remediation to prevent an issue like this from occurring in the future. We have also added a requirement for two CA operators to participate in an event that requires the issuance of a certificate from the CA core for immediate verification of the actions performed (four-eyes principle).

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

Comment 14

[incident-reporting]

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

Otherwise, it will be closed on approximately 2026-03-17.

Comment 15

[Andrew Ayer]

For the record, I find this incident report to be pretty underwhelming given the severity of the failure. It seems like there's more that could be done to reduce the need to access the "CA core" and thus avoid the possibility of human error in the first place. But as this CA is not trusted by Mozilla, Chrome, or Apple, I don't see much point in engaging further.