2032481 - Digi- ja väestötietovirasto: Misissuance detected by PKIMetal

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Compliance, task)

Description

[incident-reporting]

CA: Digi- ja väestötietovirasto
Issues:: invalid asn1 syntax, invalid explicit text encoding

Examples:

• https://crt.sh/?id=24057137712&opt=pkimetal
• https://crt.sh/?id=23876004853&opt=pkimetal
• https://crt.sh/?id=23150829082&opt=pkimetal

crt.sh trust flags:

• 360 Browser: No
• Apple: No
• Microsoft: Yes
• Mozilla: No
• Chrome: No
• Android: No
• Gmail: No
• Java: No
• Cisco: No
• EUTL QWAC: Yes
• Adobe EUTL: No
• Adobe AATL: No
• Adobe CDS: No

Comment 1

[incident-reporting]

There does not appear to be Bugzilla account for a representative of this CA.

Comment 2

[Digi- ja väestötietovirasto]

Hello,

The root cause of these problems was a configuration error with the linting of some of our certificate profiles. These have now been corrected, and the basic constraint and policy qualifier are no longer included in newly issued certificates. We have reported this issue directly to Microsoft Trusted Root Program at [e-mail], asking for instructions on how to proceed with the certificates in question. Since these certificate profile issues do not pose any security risk to our certificate subscribers, we have not proactively revoked and renewed the certificates in question before hearing Microsoft's view on the issue. We are waiting to hear your decision on the matter.

Best regards,
Digi- ja väestötietovirasto (DVV)

Comment 3

[trusten]

Given the nature of this incident, the community would appreciate clarification regarding compliance with section 4.3.1.2 of the CA/Browser Forum Baseline Requirements, which, effective 2025-03-15, states that the CA SHALL implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it.

In particular, could CCA India please confirm:

• Whether a Linting process was implemented for the affected to-be-signed Certificate or Precertificate content,
• Whether linting results are treated as issuance-blocking,
• Whether the CA uses Linting tools that are widely adopted by the industry as contemplated by BR 4.3.1.2,
• Whether this issue resulted from missing lint coverage, integration issues, configuration gaps, or another control failure,
• Whether additional certificates with similar problems have been identified.

Additional transparency around the controls currently implemented, along with a proper incident report covering timeline, scope, root cause, and remediation, would help the community better assess the effectiveness and maturity of the CA’s compliance processes going forward.

Comment 4

[Digi- ja väestötietovirasto]

Full Incident Report

Summary
• CA Owner CCADB unique ID: A000275
• Incident description: Certificates issued under the DVV Gov. Root CA – G3 RSA and DVV Gov. Root CA – G3 ECC roots for publicly trusted TLS server authentication included forbidden basic constraint and policy qualifier attributes.
• Timeline summary:
o Non-compliance start date: Since beginning of issuance.
o Non-compliance identified date: 2/6/2026
o Non-compliance end date: 2/9/2026
• Relevant policies: CA/B Forum BR.
• Source of incident disclosure: PKIMeta

Impact
• Total number of certificates: approximately 2500
• Total number of "remaining valid" certificates: approximately 1800
• Affected certificate types: TLS server certificates issued under the DVV Gov. Root CA – G3 RSA and DVV Gov. Root CA – G3 ECC roots.
• Incident heuristic: Any TLS Server certificate issued before February 9, 2026 by the DVV Gov. Root CA – G3 RSA and DVV Gov. Root CA – G3 ECC roots are affected by this incident.
• Was issuance stopped in response to this incident, and why or why not?: No, the certificate profiles were corrected, linting was turned on for the affected certificate profiles and issuance was continued.
• Analysis: The root cause of these problems was a configuration error with the linting of some of our certificate profiles. These have been corrected, and the basic constraint and policy qualifier are no longer included in newly issued certificates. Since these certificate profile issues do not pose any security risk to our certificate subscribers, we have not proactively revoked and renewed the certificates in question before hearing Microsoft's and CCADB’s view on the issue.
• Additional considerations: DVV has reported the incident to Microsoft Trusted Root Program by email, but has not yet received directions on how to proceed with the affected certificates.

Timeline
• February 6, 2026: DVV discovered a shortcoming with the linting of certain certificate profiles.
• February 9, 2026: Linting was turned on for the certificate profiles in question, upon which the issues with the certificate profiles were discovered and corrected.
• February 18, 2026: DVV received a certificate problem report from a private individual, pointing out the issues in certificates issued earlier.
• February 27, 2026: DVV reported the incident to Microsoft Trusted Root Program.
• April 16, 2026: An incident report was made to the Bugzilla forum.

Related Incidents
Bug: 2032481
Date: April 16,2026
Description: https://bugzilla.mozilla.org/show_bug.cgi?id=2032481

Root Cause Analysis
Contributing Factor #1: Human error
• Description: Linting was not turned on for the certificate profiles in question.
• Timeline: The erroneous certificate profile has been in use until February 9, 2026.
• Detection: The error was noticed on February 6, 2026.
• Interaction with other factors: Not applicable.
• Corrective measures: Implemented a more rigorous process for reviewing changes to certificate profiles and regulation.
• Root Cause Analysis methodology used: DVV Certificate Services CP/CPS

Comment 5

[Wayne]

I don't quite know where to start with this disaster. Ultimately I'd recommend actually reading the CCADB Incident Reporting Guidelines which explain each section.

Please pay attention to the examples of bad practice:

Are there examples of “bad” practices?

1. Generic or evasive responses:

• Avoid generic statements that do not address specific issues raised in the report or in response to community questions or comments.
• Refrain from providing non-committal or ambiguous answers that might be interpreted as evasive.

2. Posturing:

• Avoid blaming others or external factors.
• Resist downplaying the severity or implications of the incident.

3. Claims that are subjective, unqualified opinions, speculative, or impossible to substantiate:

• Avoid making claims that are speculative or that cannot be corroborated (e.g. “there is no security impact due to this issue.”)

4. Non-acknowledgment of responsibility:

• Clearly accept responsibility where and when due, which helps in rebuilding trust and demonstrating accountability.

5. Superficial Root Cause Analysis:

• Avoid superficial analyses that do not thoroughly explore all contributing factors.
• Ensure that the analysis is not prematurely concluded, missing deeper systemic issues.

6. Committing to opaque actions:

• Ensure actions and follow-up work items are detailed and specific.
• Promote accountability by describing how the success of an action item can be evaluated as having been successful in addressing the root cause.

7. Inadequate monitoring post-report:

• Establish mechanisms to monitor the long-term effectiveness of implemented changes.
• Be ready to revisit and revise solutions if subsequent issues indicate that the initial response was not entirely effective.

Everything except 1, 6 and 7 apply, mainly because you haven't been asked a question, there are no action items, and therefore are no changes to monitor.

While I can't on Microsoft Root Program's behalf, their program requirements are clear:

Microsoft Root Program Requirements v1.1
...
2.1.16. TRP Participants MUST adhere to the latest version of the CCADB Policy.

The timeline in this report is suspect at best:

Timeline
• February 6, 2026: DVV discovered a shortcoming with the linting of certain certificate profiles.
• February 9, 2026: Linting was turned on for the certificate profiles in question, upon which the issues with the certificate profiles were discovered and corrected.
• February 18, 2026: DVV received a certificate problem report from a private individual, pointing out the issues in certificates issued earlier.
• February 27, 2026: DVV reported the incident to Microsoft Trusted Root Program.
• April 16, 2026: An incident report was made to the Bugzilla forum.

Your CA independently discovered and fixed certificate profile issues early February. A third-party informed you mid-February, and then late-February you get around to reporting it to your Root Program.

It is only in mid-April when any public notice of this issue is made.

At no point did your CA seem to be willing to acknowledge any faults publicly. A third-party had to force the issue, and even now you are refusing to take responsibility.

Related Incidents
Bug: 2032481
Date: April 16,2026
Description: https://bugzilla.mozilla.org/show_bug.cgi?id=2032481

That is this incident, as previously stated please actually read the incident guidelines.

Root Cause Analysis
Contributing Factor #1: Human error
• Description: Linting was not turned on for the certificate profiles in question.
• Timeline: The erroneous certificate profile has been in use until February 9, 2026.
• Detection: The error was noticed on February 6, 2026.
• Interaction with other factors: Not applicable.
• Corrective measures: Implemented a more rigorous process for reviewing changes to certificate profiles and regulation.
• Root Cause Analysis methodology used: DVV Certificate Services CP/CPS

Absolutely no action items, and dismissing the report as human error where this is long-term pattern of a lack of transparency and taking responsibility. Even now you're awaiting the Microsoft Trusted Root Program to inform you to start revoking certificates that should have been done 3 months ago. I don't want to count how many other separate incidents are involved in this report alone.

Is there any part of the DVV Certificate Services CP/CPS that you are willing to comply with? It certainly isn't a Root Cause Analysis methodology, but that may be a better use of it than stating your intended practices.

Can you at least show me that you are trying at the bare minimum?

Comment 6

[incident-reporting]

It appears that trusten intended to direct Comment #3 to DVV (not CCA India).

Also, what type of TLS server certificates were these - DV or OV?

Comment 7

[incident-reporting]

This report remains incomplete and has gone stale.

Additionally, there are outstanding questions from the community, which are expected to be addressed in a timely manner.

Digi- ja väestötietovirasto, please take action.

Comment 8

[Digi- ja väestötietovirasto]

We sincerely regret not handling this issue in a prompt manner, we should have been able to handle it more professionally. DVV is determined to provide server certificate services that are compliant with regulations.

As of February 9 2026, our newly issued server certificates have been compliant with the applicable regulations and certificate profiles. Regarding the timeline of events: The person using the handle Ophelia, who opened the top-level forum ticket (id=2032356) for this issue, contacted our support and the issue was communicated to our PKI team on February 18, 2026 (EET time zone). I believe she/he can attest to contacting us after the certificate profile change had already been implemented on February 9. Exhibit A is a certificate issued on February 3, where the issue can still be found. Exhihit B is a certificate issued on February 10, where the issue has been corrected.

Exhibit A: https://crt.sh/?id=24154911800
Exhibit B: https://crt.sh/?id=24306182355

As a result of this incident, we have undertaken the following measures:

• We are strengthening our compliance team in order to improve the monitoring of regulatory changes and adherence to compliance.
• We have implemented an internal process to review and accept all certificate profile changes and additions in our product management team.

We are still awaiting a response from Microsoft Trusted Root Program and are committed to following their judgement in this matter regarding the need to revoke the certificates in question.

Also, what type of TLS server certificates were these - DV or OV?

These are OV (eIDAS QWAC) certificates.

Whether a Linting process was implemented for the affected to-be-signed Certificate or Precertificate content,

The affected Certificate profiles did not have linting enabled. This was implemented on February 9, 2026 when the certificate profiles were corrected.

Whether linting results are treated as issuance-blocking,

When linting is in place, linting errors block issuance.

Whether the CA uses Linting tools that are widely adopted by the industry as contemplated by BR 4.3.1.2,

We currently use pkilint.

Whether this issue resulted from missing lint coverage, integration issues, configuration gaps, or another control failure,

The issue resulted from missing lint coverage on some of our certificate profiles.

Whether additional certificates with similar problems have been identified.

No similar problems have been identified. We have reviewed our server certificate profiles and checked that linting is active.

Comment 9

[Wayne]

(In reply to Digi- ja väestötietovirasto from comment #8)

As a result of this incident, we have undertaken the following measures:

• We are strengthening our compliance team in order to improve the monitoring of regulatory changes and adherence to compliance.
• We have implemented an internal process to review and accept all certificate profile changes and additions in our product management team.

We are still awaiting a response from Microsoft Trusted Root Program and are committed to following their judgement in this matter regarding the need to revoke the certificates in question.

Could you explain why no revocations have taken place?

As part of your compliance and regulatory requirements you are required to take actions without a third-party informing you to do so.

Comment 10

[Digi- ja väestötietovirasto]

Could you explain why no revocations have taken place?

Our management has currently taken the stance that forcibly revoking the certificates in question would cause a disproportionate inconvenience to our customers' operations, considering the minor flaws in the certificate profile do not constitute a security risk for our customers. The majority of the certificates in question are used in healthcare or public sector machine-to-machine APIs, so potentially disrupting their services could cause major issues. If we receive a command to revoke and reissue the certificates, we will bring up this matter again with our management.

Comment 11

[Wayne]

That is incompatible with being in the WebPKI, revocation is not a management choice to be made.

If there are serious concerns about where the certificates are being used then you should be talking to your subscribers about moving to a Private PKI environment. Your subscribers should be able to replace certificates for when urgent revocations are necessary.

If your CA had credible evidence of a key compromise would you be doing nothing for these certificates currently?

There is no difference in your revocation obligations regardless of the subscriber use-case. There have been discussions at length on here of CAs claiming usage in air traffic control, and other high-risk environments. It does not change that revocation is a MUST, not a choice.

You also need to keep the community up to date on what you are doing. The incident report does not contain a list of the certificates in question, which is required. Please read the CCADB Incident Reporting Guidelines and provide that as necessary.

We're still lacking actions items and any evidence of pre or post issuance linting being performed by your CA. You need to run an up to date linter against your entire corpus of certificates, and also manually make sure your certificate profiles comply with both the baseline requirements and your CP/S.

Comment 12

[Martijn Katerbarg]

We are still awaiting a response from Microsoft Trusted Root Program and are committed to following their judgement in this matter regarding the need to revoke the certificates in question.

I believe the Microsoft Trusted Root Program has already provided such a response, specifically, within their own root store policy (which you are required to abide by)

Specifically Section 2.1.15 states:

No single organization, including Microsoft, has the authority to grant exceptions to the Baseline Requirements. Microsoft will not grant exceptions under any circumstances.

That statement by itself, is the answer you're looking for.

Additionally, your own CPS states:

The Digital and Population Data Services Agency will revoke a certificate it has issued if an error is found in its data content.

Comment 13

[chrome-root-program]

The CA Owner subject of this report has had ample time and opportunity to adhere to the requirements defined in the CCADB Policy and Incident Reporting Guidelines. Despite prior reminders and explicit ecosystem obligations (example), the CA Owner has continuously chosen not to meet well established and well documented expectations.

Because the CA Owner has demonstrated a persistent unwillingness to meet basic incident reporting expectations, we recommend closing this bug as RESOLVED / WONTFIX.

Please be advised that the Chrome Root Program maintains a record of this unaddressed non-compliance. Should this CA Owner apply for inclusion in the Chrome Root Store in the future, this deliberate failure to fulfill basic incident reporting obligations will be evaluated as direct commentary on the CA Owner's reliability and commitment to ecosystem expectations.

Comment 14

[JR Moir]

Would anyone from Microsoft care to comment?

As a Windows user, I am disturbed that a CA like this is trusted within the MS Root program, affecting billions of users. It would be good to see action.
Also concerned as an EU citizen and that this CA is on the EUTL. I cannot imagine any action being taken, but I think it shows how the EUTL is negligent in having untrustworthy CAs on it.