Open Bug 1986968 Opened 6 months ago Updated 1 day ago

Financijska agencija (Fina): Mis-issued certificates

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: miroslav.perincic, Assigned: miroslav.perincic)

Details

(Whiteboard: [ca-compliance] [dv-misissuance])

Preliminary Incident Report

Summary

  • Incident description:
    We were informed by the Microsoft’s Trusted Root Program contact person about mis-issued certificates for SAN iPAddress 1.1.1.1 issued by Fina RDC 2020. The IP address 1.1.1.1 is well-kown public resolver operated Cloudflare.
    After receiving the Microsoft’s notification, an investigation was conducted into the issuance of the TLS/SSL OVCP certificates with IP address 1.1.1.1. The investigation was conducted that all the certificates reported were issued solely as internal test certificates for the production environment, but with the mistakenly IP address added, so that they contained an unintentional error. These certificates (and corresponding private keys) were used only by the CA for testing its production. None of these certificates have been used outside the CA environment at Fina.
    Three reported certificates were revoked today, while all other registered certificates had previously been already revoked.
    We have stopped any further possibility of issuing those internal test certificates so that the detected problem does not happen again.
    We have informed the contact person of Cloudflare by email about issuing internal test certificates with IP address 1.1.1.1 and informed about him of the above.
    In issuing the internal test certificates the CA followed the procedure specified in its Certification Practice Statement for Certificates for Website Authentication, Version 1.12, Effective date: 25 November 2024 (https://rdc.fina.hr/RDC2015/CPSWSA1-12-en.pdf), Chapter 9.17, paragraph 3. This procedure will be revised and amended to ensure the issuance internal test certificates without jeopardizing the normative provisions related to TLS/SSL certificates.

  • Relevant policies:
    Certification Practice Statement for Certificates for Website Authentication, Version 1.12, Effective date: 25 November 2024 (https://rdc.fina.hr/RDC2015/CPSWSA1-12-en.pdf), Chapter 9.17, paragraph 3.

  • Source of incident disclosure:
    Self Reported

Assignee: nobody → miroslav.perincic
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [dv-misissuance]

As mentioned earlier on Mastodon, I have two observations here:

  1. You have also issued a certificate for 2.2.2.2 (serial f1:5a:47:47:cc:37:c2:59:00:00:00:00:5f:c8:cd:ed), which has been revoked on September 4, 6:34 UTC (presumably along the mis-issued 1.1.1.1 certificates). This certificate was not mentioned here, along a number of other mis-issued certs (see dev-security-policy for details, maybe someone else wants to pick up these cases). Is Oracle aware that you issued a cert for an IP in their address space? How did the misissuance happen in the case of 2.2.2.2?

  2. Why were you using revocation reason #5 (cessationOfOperation)? According to the BR, that reason is reserved for the following use case:

The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name) (CRLReason #5, cessationOfOperation);
In my opinion, this is not the case here. Neither 1.1.1.1 nor 2.2.2.2 have ceased operation or changed proprietors. I think that you should have used reason #4 (superseded):
The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded).
This is precisely the case here: The validation was unreliable. In fact, it was non-existent.
As an interested third party, I'm looking forward to your rationale for this.

Flags: needinfo?(miroslav.perincic)

(In reply to Christopher Kunz from comment #1)

In my opinion, this is not the case here. Neither 1.1.1.1 nor 2.2.2.2 have ceased operation or changed proprietors. I think that you should have used reason #4 (superseded)

I think it could also be “keyCompromise” because the secret key is known to someone who is not owner of the certified address. This also indicates that even past signatures made with this key have to be distrusted.

(In reply to Christopher Kunz from comment #1)

As mentioned earlier on Mastodon, I have two observations here:

  1. You have also issued a certificate for 2.2.2.2 (serial f1:5a:47:47:cc:37:c2:59:00:00:00:00:5f:c8:cd:ed), which has been revoked on September 4, 6:34 UTC (presumably along the mis-issued 1.1.1.1 certificates). This certificate was not mentioned here, along a number of other mis-issued certs (see dev-security-policy for details, maybe someone else wants to pick up these cases). Is Oracle aware that you issued a cert for an IP in their address space? How did the misissuance happen in the case of 2.2.2.2?

Yes, we have informed Oracle about mis-issuing certificates with IP address 2.2.2.2, that the certificate was issued solely as internal test certificates for our (CA) production environment, but with the mistakenly IP address 2.2.2.2 added. Also, we stated that the certificate and corresponding private key was used only by our CA for testing and that the corresponding private key was destroyed in Fina.

Flags: needinfo?(miroslav.perincic)
Component: CA Security Vulnerability → CA Certificate Compliance

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A005748

  • Incident description:
    We were informed by the Microsoft’s Trusted Root Program contact person about mis-issued certificates for SAN iPAddress 1.1.1.1 issued by Fina RDC 2020. The IP address 1.1.1.1 is well-known public resolver.
    After receiving the Microsoft’s notification, an investigation was conducted into the issuance of the TLS/SSL OVCP certificates with IP address 1.1.1.1. The investigation was conducted that all the certificates reported were issued solely as internal test certificates for the production environment, but with the mistakenly IP address added, so that they contained an unintentional error. These certificates (and corresponding private keys) were used only by the CA for testing its production. None of these certificates have been used outside the CA environment at Fina.
    Three reported certificates were revoked on 2025-09-04, while all other registered certificates had previously been already revoked.
    We have stopped any further possibility of issuing those internal test certificates so that the detected problem does not happen again.
    We have informed the contact person of the owner of IP address 1.1.1.1 by email about issuing internal test certificates with that IP address and informed about him of the above. Also, we have informed the owner of IP address 2.2.2.2 about one mis-issuing certificate for that IP address, that the certificate was issued solely as internal test certificates for our (CA) production environment, but with the mistakenly IP address 2.2.2.2 added. Also, we stated that the certificate was revoked on 2025-09-04, and corresponding private key was used only by our CA for testing and that the corresponding private key was destroyed in Fina.
    In issuing the internal test certificates the CA followed the procedure specified in its Certification Practice Statement for Certificates for Website Authentication, Version 1.12, Effective date: 25 November 2024 (https://rdc.fina.hr/RDC2015/CPSWSA1-12-en.pdf), Chapter 9.17, paragraph 3. This procedure will be revised and amended to ensure the issuance internal test certificates without jeopardizing the normative provisions related to TLS/SSL certificates.

  • Timeline summary:

    • Non-compliance start date:
      2024-02-18 11:07 Issuing test certificate for IP address 1.1.1.1.
    • Non-compliance identified date:
      2025-09-04 Non-compliance was detected after analyzing the notice sent by Microsoft Trusted Root Program.
    • Non-compliance end date:
      2025-09-04 08:00 We have prevented this irregularity from recurring and we expect that the non-compliance end date will be on 2025-09-26.

  • Relevant policies:
    Certification Practice Statement for Certificates for Website Authentication, Version 1.12, Effective date: 25 November 2024 (https://rdc.fina.hr/RDC2015/CPSWSA1-12-en.pdf), Chapter 9.17, paragraph 3.

  • Source of incident disclosure:
    Self Reported

Impact

  • Total number of certificates:
    The total number of affected certificates is 13.
  • Total number of "remaining valid" certificates:
    There are no "remaining valid" certificates.
  • Affected certificate types:
    This incident affects OV certificates issued for IP address for which authorization was not requested.
  • Incident heuristic:
    This incident affected 13 certificates issued between 2024-02-18 11:07:33 and 2025-08-26 07:54:54.
  • Was issuance stopped in response to this incident, and why or why not?:
    Yes, the issuance was stopped in response to this incident. Since these certificates are intended solely for internal testing, the issuance of these certificates occurred rarely. As described in the incident timeline, issuance has been stopped on 2025-09-04 08:00.

Timeline

  • 2019-06-10 00:00 UTC-02 Certification Practice Statement for Certificates for Website Authentication ver. 1.4 came into force with the regulated possibility of issuing test certificates for the purpose of internal tests of the production CA environment
  • 2024-02-18 11:07 Issuing of first internal test certificate for IP address 1.1.1.1
  • 2025-09-03 14:03:36 Initial notice received in Fina sent from the owner of IP address 1.1.1.1 about several certificates issued for that IP address.
  • 2025-09-03 16:39 Notification about the incident with question, received by e-mail from Microsoft Trusted Root Program
  • 2025-09-04 06:34:38 Last affected certificate revoked.
  • 2025-09-04 06:51 Reply sent to Microsoft Trusted Root Program in which Fina confirmed the issuance of the affected certificates.
  • 2025-09-04 08:00 Stopping the issuing of certificates for internal testing.
  • 2025-09-04 11:13 Croatian Supervisory Body in charge of eIDAS Regulation (Regulation (EU) No 910/2014) has been informed about incident
  • 2025-09-04 12:44 Replay has been sent to the owner of IP address 1.1.1.1 in which Fina confirmed the issuance of the affected certificates with additional information about the purpose of affected certificates, their revocation and destroying their related private keys.
  • 2025-09-04 16:47 Preliminary Incident Report has been published Bugzilla (Bug 1986968).
  • 2025-09-04 16:54 Microsoft Trusted Root Program has been informed about published Preliminary Incident Report
  • 2025-09-05 13:22 Notification e-mail was sent to the owner of IP address 2.2.2.2 about one mis-issued certificate for that IP address.
  • 2025-09-10 08:16 Email from the Croatian Supervisory Body in charge of eIDAS Regulation has been received with request for additional information.
  • 2025-09-11 07:00 Internal special ISMS audit has been performed according to ISO:IEC 27001:2022 standard on the scope related to
  • 2025-09-12 10:13 Email with requested additional information and proposed measures has been sent to Croatian Supervisory Body in charge of eIDAS Regulation
  • 2025-09-16 13:00 Email from the Croatian Supervisory Body in charge of eIDAS Regulation has been received with confirming proposed measures and request for performing an eIDAS conformity assessment by Conformity Assessment Body as soon as possible.

Root Cause Analysis

Contributing Factor 1: Incompletely defined process of issuing testing certificates

  • Description:
    Process of issuing test certificates for testing the production CA environment was not completely defined. The defined set of values that can be entered in the SAN extension for such certificates (such as the IP address) are missing, as are other details necessary for better control of the issuance of these certificates, including their publication. There is also a lack of specification of the deadline for revoking such certificates.

Contributing Factor 2: Incompletely defined checking process

  • Description:
    The internal periodic certificate audit process of issued certificates was primarily focused on user (subscriber) certificates, but it didn't focus enough on certificates that weren’t requested by user (subscriber), ie. test certificates issued in production environment.

**Contributing Factor 3: Insufficient training and awareness **

  • Description:
    Insufficient training and awareness on certain topics of some CA staff, especially in case of training of new employees and their induction into work. This led to lack of the necessary level of caution and recognition of a possible problem while performing assigned tasks.

Lessons Learned

  • What went well:
    Most of the affected certificates were revoked in a timely manner. The corresponding private keys of all affected certificates did not leave a controlled CA environment and were regularly destroyed.
  • What didn’t go well:
    Affected certificates that were not issued to intended only for internal testing in CA environment were issued for an IP addresses that were not appropriate and that were mistakenly applied because of the root causes stated above.
  • Where we got lucky:
    There was no security threat for CA subscribers.

The scope of this mis-issuance incident appears to be broader than the initially reported certificates for the IP addresses 1.1.1.1 and 2.2.2.2. As noted by Wayne in the dev-security-policy mailing list on September 5, 2025, several other non-compliant certificates have been discovered.

Categories of Mis-issuance

The additional certificates fall into three main categories:

  • Reserved IP Addresses: Certificates issued with an iPAddress SAN entry containing a reserved (private) IPv4 address (e.g., from the 10.0.0.0/8 block).
  • Internal Names: Certificates issued where the Subject CommonName or a dNSName SAN entry contains an Internal Name (e.g., a bare hostname without a TLD).
  • Non-LDH Labels: Certificates issued where the Subject CommonName or a dNSName SAN entry contains a label with non-LDH characters (e.g., spaces or underscores).

As of today (2025-09-19), these certificates have not yet been revoked.

Violation of Baseline Requirements

This issuance is a clear violation of the CA/Browser Forum's TLS Baseline Requirements (v2.1.7), including:

  • Section 4.2.2, which prohibits CAs from issuing certificates containing Internal Names or Reserved IP Addresses.

    CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.

  • Section 7.1.2.7.12, which states that dNSName SAN entries must not contain Internal Names and must be composed of LDH labels.

    The entry MUST NOT contain an Internal Name.
    The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (“.”) character.

  • Section 7.1.4.3, which mandates that all domain labels within Subject CommonName must be encoded as LDH labels.

    Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.

Questions for Fina

Given this new information, I have the following questions:

  1. Why were these additional categories of non-compliant certificates omitted from the incident report? Was Fina's investigation limited only to the 1.1.1.1 and 2.2.2.2 certificates?
  2. What steps is Fina now taking to perform a comprehensive search for all other certificates that may violate the Baseline Requirements in similar ways?
Flags: needinfo?(miroslav.perincic)

  1. I'm also curious about how the certificates includes hostnames that would be valid hostnames, but don't seem to exist. For example, the cert logged at https://crt.sh/?id=18603461241 in addition to including 1.1.1.1, includes test1.hr and test12.hr. Neither of those names seem to exist (yet) as far as I can tell. I would have expected the report to include explaining them, in addition to explaining how the IP entries are in there.

  2. The "Root Cause Analysis" seems to be mostly about immediate causes, not root causes. For instance, why was the process of issuing test certificates for testing the production CA environment not completely defined? Why was the internal periodic certificate audit process of issued certificates primarily focused on user (subscriber) certificates? Why was there insufficient training and awareness on certain topics of some CA staff? I think that a lot more detail could be included on the processes that led to the current issues, and how those processes were developed.

  3. How did the CPS end up with the paragraph in section 9.17 saying that these test certificates could be signed, even though section 1.1.2 says that the CA follows the Baseline Requirements? What's the process used to review the CPS regularly (and when Baseline Requirements change) to ensure that the CPS stays consistent with them? What internal or external auditing exists that might have been able to catch that the paragraph was describing certificates that shouldn't be allowed to be signed in production?

Will Fina please answer, with specificity, the following two questions:

1. Pre-incident testing procedures: What was Fina’s process for issuing “test certificates” prior to this incident, including the technical steps, approval flows, SAN value selection, certificate/key handling, and oversight or auditing mechanisms?

2. Post-incident remediation: What exact changes has Fina implemented (or committed to implement) to prevent recurrence? Please identify the revised procedures, technical controls, CPS amendments, audit mechanisms, and staff training or awareness measures being put in place, and provide Due Dates for adoption or completion of all Action Items. See https://www.ccadb.org/cas/incident-report which requires a schedule of Action Items.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Example Prevent Root Cause # 1 Criteria 2025-mm-dd Value

(In reply to Stephan Verbücheln from comment #2)

I think it could also be “keyCompromise” because the secret key is known to someone who is not owner of the certified address. This also indicates that even past signatures made with this key have to be distrusted.

I don't think that applies here. Per Mozilla's wiki on Revocation Reasons, keyCompromise is for use in cases where the private key corresponding to a subscriber's certificate is breached or weak in some way.

In this case, Fina was self-issuing themselves a certificate, and there was no problem relating to the private key. Cloudflare (for 1.1.1.1) was never a subscriber, so the fact that they don't have control of the key isn't relevant.

(In reply to Matthew McPherrin from comment #8)

In this case, Fina was self-issuing themselves a certificate, and there was no problem relating to the private key. Cloudflare (for 1.1.1.1) was never a subscriber, so the fact that they don't have control of the key isn't relevant.

First of all, there is a core misunderstanding here. The primary duty of a CA is not to their subscribers but to the general public who trusts their certificates.

Given that, any private key for a domain or IP address certificate which is controlled by someone other than the owner (or an entity chosen by the owner, e.g., an employee or a service partner) is a breach.
And why does this matter? Different revocation reasons have different meanings. Some mean: “This certificate is not used any longer. Do not trust it in the future.”
Others mean: “This certificate was not secure the whole time. Do not trust any past, present or future uses.”
In one case, a document signed in the past can still be considered valid, in the other case not.

The certificate for 1.1.1.1 has the revocation code “cessationOfOperation”, which does not fit at all.
https://crt.sh/?id=20582951233
https://wiki.mozilla.org/CA/Revocation_Reasons

(In reply to Youfu Zhang from comment #5)

The scope of this mis-issuance incident appears to be broader than the initially reported certificates for the IP addresses 1.1.1.1 and 2.2.2.2. As noted by Wayne in the dev-security-policy mailing list on September 5, 2025, several other non-compliant certificates have been discovered.

Categories of Mis-issuance

The additional certificates fall into three main categories:

  • Reserved IP Addresses: Certificates issued with an iPAddress SAN entry containing a reserved (private) IPv4 address (e.g., from the 10.0.0.0/8 block).
  • Internal Names: Certificates issued where the Subject CommonName or a dNSName SAN entry contains an Internal Name (e.g., a bare hostname without a TLD).
  • Non-LDH Labels: Certificates issued where the Subject CommonName or a dNSName SAN entry contains a label with non-LDH characters (e.g., spaces or underscores).

As of today (2025-09-19), these certificates have not yet been revoked.

Violation of Baseline Requirements

This issuance is a clear violation of the CA/Browser Forum's TLS Baseline Requirements (v2.1.7), including:

  • Section 4.2.2, which prohibits CAs from issuing certificates containing Internal Names or Reserved IP Addresses.

    CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5.

  • Section 7.1.2.7.12, which states that dNSName SAN entries must not contain Internal Names and must be composed of LDH labels.

    The entry MUST NOT contain an Internal Name.
    The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (“.”) character.

  • Section 7.1.4.3, which mandates that all domain labels within Subject CommonName must be encoded as LDH labels.

    Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.

Questions for Fina

Given this new information, I have the following questions:

  1. Why were these additional categories of non-compliant certificates omitted from the incident report? Was Fina's investigation limited only to the 1.1.1.1 and 2.2.2.2 certificates?

At the first step investigation was initially focused on the 1.1.1.1 and 2.2.2.2 test certificates because we considered this case to be the most important case due to the possible threat, so the incident report was focused to these certificates. Additional categories of non-compliant certificates are also included in the next step of investigation as for1.1.1.1 and 2.2.2.2 test certificates.

  1. What steps is Fina now taking to perform a comprehensive search for all other certificates that may violate the Baseline Requirements in similar ways?

We are investigating certificates that have any of the categories of reported errors in the SAN extension: certificates that contain Reserved IP address, Internal Names or labels with non-LDH characters in the SAN extension. Also, we are performing in-depth analyses and checks of the causes that led to the errors in the process of verifying this data and issuing a certificate

[edited by dveditz to separate response from quoted matter]

Flags: needinfo?(miroslav.perincic)

(In reply to Peter Cooper Jr. from comment #6)

  1. I'm also curious about how the certificates includes hostnames that would be valid hostnames, but don't seem to exist. For example, the cert logged at https://crt.sh/?id=18603461241 in addition to including 1.1.1.1, includes test1.hr and test12.hr. Neither of those names seem to exist (yet) as far as I can tell. I would have expected the report to include explaining them, in addition to explaining how the IP entries are in there.

  2. The "Root Cause Analysis" seems to be mostly about immediate causes, not root causes. For instance, why was the process of issuing test certificates for testing the production CA environment not completely defined? Why was the internal periodic certificate audit process of issued certificates primarily focused on user (subscriber) certificates? Why was there insufficient training and awareness on certain topics of some CA staff? I think that a lot more detail could be included on the processes that led to the current issues, and how those processes were developed.

  3. How did the CPS end up with the paragraph in section 9.17 saying that these test certificates could be signed, even though section 1.1.2 says that the CA follows the Baseline Requirements? What's the process used to review the CPS regularly (and when Baseline Requirements change) to ensure that the CPS stays consistent with them? What internal or external auditing exists that might have been able to catch that the paragraph was describing certificates that shouldn't be allowed to be signed in production?

  1. Certificates that have a value beginning with test in the first left component of the FQDN were, according to the CPS, considered test certificates. Root Cause Analysis processed test certificates and the analysis also applies to mis-issued certificates that in SAN extension have test1.hr and test12.hr.
    (In reply to Peter Cooper Jr. from comment #6)

  1. I'm also curious about how the certificates includes hostnames that would be valid hostnames, but don't seem to exist. For example, the cert logged at https://crt.sh/?id=18603461241 in addition to including 1.1.1.1, includes test1.hr and test12.hr. Neither of those names seem to exist (yet) as far as I can tell. I would have expected the report to include explaining them, in addition to explaining how the IP entries are in there.

  2. The "Root Cause Analysis" seems to be mostly about immediate causes, not root causes. For instance, why was the process of issuing test certificates for testing the production CA environment not completely defined? Why was the internal periodic certificate audit process of issued certificates primarily focused on user (subscriber) certificates? Why was there insufficient training and awareness on certain topics of some CA staff? I think that a lot more detail could be included on the processes that led to the current issues, and how those processes were developed.

  3. How did the CPS end up with the paragraph in section 9.17 saying that these test certificates could be signed, even though section 1.1.2 says that the CA follows the Baseline Requirements? What's the process used to review the CPS regularly (and when Baseline Requirements change) to ensure that the CPS stays consistent with them? What internal or external auditing exists that might have been able to catch that the paragraph was describing certificates that shouldn't be allowed to be signed in production?

  1. Certificates that have a value beginning with test in the first left component of the FQDN were, according to the CPS, considered test certificates. Root Cause Analysis processed test certificates and the analysis also applies to mis-issued certificates that in SAN extension have test1.hr and test12.hr.
  2. The process was not fully defined due to a higher turnover of persons in charge of defining procedures.
    Considering that test certificates are issued rarely and exclusively for internal testing purposes, process of checking the certificates was focused on user certificates. Checking of user certificates is performed on a sample, as prescribed, but by oversight the test certificates were not included in the sample.
    Education and awareness were performed periodically and according to changes, but this case shows that education and awareness were not carried out successfully enough, and in some cases due to higher employee turnover, not often enough.
    Due to the above, an oversight caused by the human factor occurred, and due to insufficient awareness of the consequences of mis-issued certificate, a series of errors occurred.
    Due care was not taken to prevent human error. Insufficiently strong education and awareness have a significant impact on this case.
    In-depth analyses and checks are currently being carried out. The aim is to ensure that these mistakes do not happen again, and one of the measures for this will be an improved method of implementing controls.
  3. Regulated possibility of issuing test certificates in section 9.17 of CPS was formed due to the need for testing in of the production CA environment and was formed according to section 6.9.2. of ETSI 319 411-1 document where such a possibility is regulated. CPS is regularly reviewed at least once a year, or in case in the event of a perceived need for change, which includes changes in normative documents that are applicable for providing service.
    The audits that are performed and that might have been able to catch the noticed paragraph are internal and external audits that are performed in full scope and in accordance with the eIDAS regulation and ETSI EN 319 403 norm. These audits are performed regularly on an annual basis and before implementing any significant change. Fina eliminates any detected irregularity, regardless of its severity level, within the agreed deadlines. Also, Croatian Supervisory Body in charge of eIDAS Regulation has requested Fina to engage Conformity Assessment Body (CAB) to perform external eIDAS audit according to the relevant ETSI norms, as soon as possible. In order to eliminate possible irregularities that may have not been noticed until now, Fina has to engaged CAB who has not performed audits at Fina so far.

Does Fina use software for linting before issuing of TLS certificates?
Are all TLS from Fina logged into Certificate Transparency?
Who is new Conformity Assessment Body now?

This case shows FINA is not professional organisation as a CA, absolutely.

Citadel Core Security Team is curious how Microsoft’s CA Program team review and approve FINA’s inclusion request? Is this material convenient for disclosure publicly?

Flags: needinfo?(CentralPKI)

The response times are really disappointing.

Please also note that Financijska Agencija is a government-mandated certificate authorities of the kind which the EU wanted to force on browser vendors a few years ago.

https://www.eff.org/deeplinks/2021/12/eus-digital-identity-framework-endangers-browser-security
https://rdc.fina.hr/dokumentacija/eIDAS_certificate_profile.pdf
https://www.eid.as/fileadmin/eidas-tsp-map/

We apologize for the long pause in answering questions.
As previously stated, we have initiated the procurement of the eIDAS conformity assessment (audit) which will be carried out by Conformity Assessment Body who has not yet been engaged in Fina, as requested by the national Supervisory Body in charge of eIDAS Regulation. Please understand that we are obliged to carry out this procurement according to the national law on public procurement, and that when contacting potentially interested auditors, we regularly received a response about the occupation of their appointments. At the moment we do not know which auditor will conduct this audit because the procurement process is ongoing, but in the meantime, we are conducting internal checks of procedures and checking compliance with regulatory requirements.
We will eliminate any deviations which we identify and which the external auditor identifies during the audit, in agreement with the auditor and as soon as possible.

Over the last month, there does not appear to have been a reply to the two questions from comment #7.
When will these be answered?

Flags: needinfo?(CentralPKI)

I removed the needinfo because it was directed to the wrong entity / email address.

Flags: needinfo?(miroslav.perincic)

(In reply to Ben Wilson from comment #7)

Will Fina please answer, with specificity, the following two questions:

1. Pre-incident testing procedures: What was Fina’s process for issuing “test certificates” prior to this incident, including the technical steps, approval flows, SAN value selection, certificate/key handling, and oversight or auditing mechanisms?

2. Post-incident remediation: What exact changes has Fina implemented (or committed to implement) to prevent recurrence? Please identify the revised procedures, technical controls, CPS amendments, audit mechanisms, and staff training or awareness measures being put in place, and provide Due Dates for adoption or completion of all Action Items. See https://www.ccadb.org/cas/incident-report which requires a schedule of Action Items.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Example Prevent Root Cause # 1 Criteria 2025-mm-dd Value

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Decision on banning the issuance of certificates Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-09-04 Completed
Employee training on requirements and procedures for providing trust services (part 1) Prevent Root Cause #3 Increasing the level of caution and recognition of possible problems when performing assigned tasks. 2025-09-16 Completed
Audit and non-conformities management procedure for the area of providing trust services Detect Root Cause #1, #2 and #3 Planning and managing internal and supplier audits 2025-11-17 Completed
New version of CPS (Certification Practice Statement for Certificates for Website Authentication, Ver. 1.13) Prevent Root Cause #1 All issued certificates are considered certificates issued to Subscribers. 2025-11-24 Completed
Procedure for Issuing Production Certificates for Testing the Fina PKI System Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-12-02 Ongoing
Employee training on requirements and procedures for providing trust services (part 2) Prevent Root Cause # 3 Gaining greater confidence and independence in work. 2025-12-09 Ongoing
Internal audit according to eIDAS regulation, ETSI 319 411-1, ETSI 319411-2 and the Baseline Requirements document Detect Root Cause: #1, #2 and #3 Compliance with relevant regulatory requirements 2025-12-10 Ongoing
eIDAS conformity assessment by CAB (external full audit in full scope) according to eIDAS regulation, ETSI norms and the Baseline Requirements document Detect Root Cause #1, #2 and #3 Confirmation of compliance with relevant regulatory requirements 2026-01-16 Ongoing
Flags: needinfo?(miroslav.perincic)

(In reply to Charter77 from comment #12)

Does Fina use software for linting before issuing of TLS certificates?
We had problems setting up the linting process, so certificates were issued without using linting software, but with increased attention to meet the requirements for the certificate profile. We are working on fixing and establishing the linting process.`

Are all TLS from Fina logged into Certificate Transparency?
Almost all TLS/SSL certificates issued by Fina are logged into Certificate Transparency. Only qualified certificate for website authentication for PSD2 (33 currently valid certificates) are not logged into Certificate Transparency.

Who is new Conformity Assessment Body now?
We are obliged to conduct procurements in accordance with the national public procurement law. The process of public procurement of the extraordinary external audit which will be carried out by the CAB (which so far has not conducted an audit in Fina) is in its final phase. We currently do not have a contract yet, but we expect the contract with CAB to be concluded during the first two weeks of December. After that, we will publish information about the name of that CAB.

We had problems setting up the linting process, so certificates were issued without using linting software

Can you expand on what the problems you encountered were? It seems like a surprising roadblock without additional detail since many other CAs have successfully implemented certificate linting, including some that issue over 10 million certificates a day.

We are working on fixing and establishing the linting process.

It seems to me this should be listed as an action item and given a due date.

Could Fina expand, based on this comment, how it complied with Section 4.3.1.2 of the TLS BRs?

In addition to the question asked in comment #20, which linting software is Fina planning to utilize?

(In reply to Daniel McCarney from comment #20)

We had problems setting up the linting process, so certificates were issued without using linting software

Can you expand on what the problems you encountered were? It seems like a surprising roadblock without additional detail since many other CAs have successfully implemented certificate linting, including some that issue over 10 million certificates a day.

We are working on fixing and establishing the linting process.

It seems to me this should be listed as an action item and given a due date.

Our goal was to submit a to-be-signed precertificate to the linting process because that's how we interpreted the requirement in Section 4.3.1.2 of the Baseline Requirements document, but we couldn't get the to-be-signed precertificate from the CA software we're currently using. From the CA software we use, we can only get digitally signed precertificate and we can only submit such digitally signed precertificate to the linting process.

Since such a proceeding, according to our understanding, might not be fully in accordance with the requirement from Section 4.3.1.2, we planned to implement the linting process on a new ECC-based infrastructure that will use another CA software. This CA software will be able to deliver the to-be-signed precertificate to linting process. The new ECC-based infrastructure with another CA software we plan to establish in second quarter 2026.

The only way we can currently establish the linting process is to submit a digitally signed precertificate for linting. We can establish this process until 15.12.2025. In the event that an error is detected in the pre-certificate during the linting process, the precertificate/certificate will be revoked, the precertificate will not be published in CT Log servers and the certificate will not be issued.

This should be listed as an action item and given a due date.

(In reply to Martijn Katerbarg from comment #21)

Could Fina expand, based on this comment, how it complied with Section 4.3.1.2 of the TLS BRs?

Clarification of the process that we can implement with the existing CA software we're currently using is stated in the comment #22 (that is a reply to comment #20).

In addition to the question asked in comment #20, which linting software is Fina planning to utilize?

Fina is working on establishing the use of the ZLint software.

(In reply to miroslav.perincic from comment #19)

(In reply to Charter77 from comment #12)

Does Fina use software for linting before issuing of TLS certificates?
We had problems setting up the linting process, so certificates were issued without using linting software, but with increased attention to meet the requirements for the certificate profile. We are working on fixing and establishing the linting process.`

Are all TLS from Fina logged into Certificate Transparency?
Almost all TLS/SSL certificates issued by Fina are logged into Certificate Transparency. Only qualified certificate for website authentication for PSD2 (33 currently valid certificates) are not logged into Certificate Transparency.

Who is new Conformity Assessment Body now?
We are obliged to conduct procurements in accordance with the national public procurement law. The process of public procurement of the extraordinary external audit which will be carried out by the CAB (which so far has not conducted an audit in Fina) is in its final phase. We currently do not have a contract yet, but we expect the contract with CAB to be concluded during the first two weeks of December. After that, we will publish information about the name of that CAB.

This is an addition to the answer to the 3rd question asked in comment #12.
The process of public procurement of the extraordinary external audit is finished and the contract has been concluded. The Conformity Assessment Body, which so far has not conducted an audit in Fina, is TAYLLORCOX s.r.o., based in Praha, Czech Republic. The first stage of audit will start on 2025-12-15.

Status Update

This is the updated status of the initial table "Action Items" from comment #18. These are the changes made:

  • Update on the action item 5: Procedure for Issuing Production Certificates for Testing the Fina PKI System is in the process of being adopted. A new Due Date has been specified.
  • Update on the action item 6: The employee training is in preparation. A new Due Date has been specified.
  • Update on the action item 7: Internal audit according to eIDAS regulation is completed.
  • The action item 9 “Setting up the linting process” has been added.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
1 Decision on banning the issuance of certificates Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-09-04 Completed
2 Employee training on requirements and procedures for providing trust services (part 1) Prevent Root Cause #3 Increasing the level of caution and recognition of possible problems when performing assigned tasks. 2025-09-16 Completed
3 Audit and non-conformities management procedure for the area of providing trust services Detect Root Cause #1, #2 and #3 Planning and managing internal and supplier audits 2025-11-17 Completed
4 New version of CPS (Certification Practice Statement for Certificates for Website Authentication, Ver. 1.13) Prevent Root Cause #1 All issued certificates are considered certificates issued to Subscribers. 2025-11-24 Completed
5 Procedure for Issuing Production Certificates for Testing the Fina PKI System Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-12-19 Delayed
6 Employee training on requirements and procedures for providing trust services (part 2) Prevent Root Cause # 3 Gaining greater confidence and independence in work. 2025-12-19 Delayed
7 Internal audit according to eIDAS regulation, ETSI 319 411-1, ETSI 319 411-2 and the Baseline Requirements document Detect Root Cause: #1, #2 and #3 Compliance with relevant regulatory requirements 2025-12-10 Completed
8 eIDAS conformity assessment by CAB (external full audit in full scope) according to eIDAS regulation, ETSI norms and the Baseline Requirements document Detect Root Cause #1, #2 and #3 Confirmation of compliance with relevant regulatory requirements 2026-01-16 Ongoing
9 Setting up the linting process Prevent Root Cause #2 A very small possibility that the certificate contains technical errors and inconsistencies in relation to the certificate profile regulated by the CAB Forum Baseline Requirements document. 2025-12-12 Completed

This report has gone stale. As per https://www.ccadb.org/cas/incident-report#when-are-reports-updated, updates should be posted every 7 days unless a proposed Next Update has been accepted.

Status Update

These are the changes made:

  • Update on action item 5: The new version of the Procedure for Issuing Production Certificates for Testing the Fina PKI System is adopted and entered into force.
  • Update on action item 6: A new due date of the employee training (part 2) has been set because the training has been postponed to the first part of January.
  • Information related to item 8: The Stage 1 (documentation audit) of eIDAS conformity assessment conducted by CAB ended on December 19, 2025. The Stage 2 of the audit will start on January 12, 2026.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
1 Decision on banning the issuance of certificates Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-09-04 Completed
2 Employee training on requirements and procedures for providing trust services (part 1) Prevent Root Cause #3 Increasing the level of caution and recognition of possible problems when performing assigned tasks. 2025-09-16 Completed
3 Audit and non-conformities management procedure for the area of providing trust services Detect Root Cause #1, #2 and #3 Planning and managing internal and supplier audits 2025-11-17 Completed
4 New version of CPS (Certification Practice Statement for Certificates for Website Authentication, Ver. 1.13) Prevent Root Cause #1 All issued certificates are considered certificates issued to Subscribers. 2025-11-24 Completed
5 Procedure for Issuing Production Certificates for Testing the Fina PKI System Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-12-23 Completed
6 Employee training on requirements and procedures for providing trust services (part 2) Prevent Root Cause # 3 Gaining greater confidence and independence in work. 2026-01-09 Delayed
7 Internal audit according to eIDAS regulation, ETSI 319 411-1, ETSI 319 411-2 and the Baseline Requirements document Detect Root Cause: #1, #2 and #3 Compliance with relevant regulatory requirements 2025-12-10 Completed
8 eIDAS conformity assessment by CAB (external full audit in full scope) according to eIDAS regulation, ETSI norms and the Baseline Requirements document Detect Root Cause #1, #2 and #3 Confirmation of compliance with relevant regulatory requirements 2026-01-16 Ongoing
9 Setting up the linting process Prevent Root Cause #2 A very small possibility that the certificate contains technical errors and inconsistencies in relation to the certificate profile regulated by the CAB Forum Baseline Requirements document. 2025-12-12 Completed

Status Update

There have been no changes to the status of planned actions in the previous seven days.

Status Update

There have been no changes to the status of planned actions in the previous seven days.

Status Update

There have been no changes to the status of planned actions in the previous period.

We have information related to item 8: The Stage 2 (on-site audit) of eIDAS conformity assessment conducted by CAB began on January 12, 2026 and is ongoing.

Status Update

These are the changes made:

  • Update on action item 8: eIDAS conformity assessment by CAB (external full audit in full scope) has been completed in terms of visit and inspection of the auditor. At the beginning of February, we will receive Conformity Assessment Report and Attestation Letter.
  • Update on action item 6: A new due date of the employee training (part 2) has been set because the training has been postponed due to support for conducting an external audit from the item 8.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
1 Decision on banning the issuance of certificates Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-09-04 Completed
2 Employee training on requirements and procedures for providing trust services (part 1) Prevent Root Cause #3 Increasing the level of caution and recognition of possible problems when performing assigned tasks. 2025-09-16 Completed
3 Audit and non-conformities management procedure for the area of providing trust services Detect Root Cause #1, #2 and #3 Planning and managing internal and supplier audits 2025-11-17 Completed
4 New version of CPS (Certification Practice Statement for Certificates for Website Authentication, Ver. 1.13) Prevent Root Cause #1 All issued certificates are considered certificates issued to Subscribers. 2025-11-24 Completed
5 Procedure for Issuing Production Certificates for Testing the Fina PKI System Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-12-23 Completed
6 Employee training on requirements and procedures for providing trust services (part 2) Prevent Root Cause # 3 Gaining greater confidence and independence in work. 2026-01-30 Delayed
7 Internal audit according to eIDAS regulation, ETSI 319 411-1, ETSI 319 411-2 and the Baseline Requirements document Detect Root Cause: #1, #2 and #3 Compliance with relevant regulatory requirements 2025-12-10 Completed
8 eIDAS conformity assessment by CAB (external full audit in full scope) according to eIDAS regulation, ETSI norms and the Baseline Requirements document Detect Root Cause #1, #2 and #3 Confirmation of compliance with relevant regulatory requirements 2026-01-16 Completed
9 Setting up the linting process Prevent Root Cause #2 A very small possibility that the certificate contains technical errors and inconsistencies in relation to the certificate profile regulated by the CAB Forum Baseline Requirements document. 2025-12-12 Completed

Status Update

There have been no changes to the status of planned actions in the previous seven days.

Status Update

There have been no changes to the status of planned actions in the previous seven days.

Related to the Action Item 8, we expect to receive the Conformity Assessment Report and Audit Attestation Letter from external eIDAS auditor (CAB) by 2026-02-10.

Status Update

These are the changes made:

  • Update on action item 6: Employee training on requirements and procedures for providing trust services (part 2) has been completed.

  • Related to the Action item 8, we received the Conformity Assessment Report (CAR) document and audit attestation letter (ALL) from the TayllorCox Conformity Assessment Body (CAB) on 10.02.2026. On the same day, we sent a notification to the Microsoft Trusted Root Program about the link to the TayllorCox site where the AAL document was published. The CAR document was forwarded to the Croatian National Supervisory a Body (NAB) in charge of eIDAS Regulation on 11.02.2026.

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
1 Decision on banning the issuance of certificates Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-09-04 Completed
2 Employee training on requirements and procedures for providing trust services (part 1) Prevent Root Cause #3 Increasing the level of caution and recognition of possible problems when performing assigned tasks. 2025-09-16 Completed
3 Audit and non-conformities management procedure for the area of providing trust services Detect Root Cause #1, #2 and #3 Planning and managing internal and supplier audits 2025-11-17 Completed
4 New version of CPS (Certification Practice Statement for Certificates for Website Authentication, Ver. 1.13) Prevent Root Cause #1 All issued certificates are considered certificates issued to Subscribers. 2025-11-24 Completed
5 Procedure for Issuing Production Certificates for Testing the Fina PKI System Prevent Root Cause # 1 No certificates have been issued that contain an unverified or irregular FQDN or IP address for which an application for issuance has not been submitted and approved. 2025-12-23 Completed
6 Employee training on requirements and procedures for providing trust services (part 2) Prevent Root Cause # 3 Gaining greater confidence and independence in work. 2026-02-13 Completed
7 Internal audit according to eIDAS regulation, ETSI 319 411-1, ETSI 319 411-2 and the Baseline Requirements document Detect Root Cause: #1, #2 and #3 Compliance with relevant regulatory requirements 2025-12-10 Completed
8 eIDAS conformity assessment by CAB (external full audit in full scope) according to eIDAS regulation, ETSI norms and the Baseline Requirements document Detect Root Cause #1, #2 and #3 Confirmation of compliance with relevant regulatory requirements 2026-01-16 Completed
9 Setting up the linting process Prevent Root Cause #2 A very small possibility that the certificate contains technical errors and inconsistencies in relation to the certificate profile regulated by the CAB Forum Baseline Requirements document. 2025-12-12 Completed

Following the extraordinary external audit (related to the Action Item 8), we opened a new case in CCADB (Case Number 00002972) and included the URL to the AAL published on the auditor's trusted location. The AAL was also sent to Microsoft Trusted Root Program.
All planned action items are complete. We continue to monitor this bug for questions and feedback.

Please note that following the CCADB Incident Reporting Guidelines updates should be provided weekly, unless a 'next update' date has been set in advance. That is a separate incident to be raised.

When are reports updated?

CA Owners SHOULD respond promptly to comments and questions, and MUST respond within 7 days, even if only to acknowledge the request and provide a timeline for a full response.

If you believe this incident is resolved please submit a closure report.

You need to log in before you can comment on or make changes to this bug.