Open Bug 1887110 Opened 4 months ago Updated 13 days ago

Microsec: Delayed revocation of the misissued certificates

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: szoke.sandor, Assigned: szoke.sandor)

Details

(Whiteboard: [ca-compliance] [leaf-revocation-delay])

Incident Report

Summary

It was reported by email to info@... , that Microsec misissued an EV certificate.
The problem is that the certificate does not contain the CPSuri link.
Microsec did not react in time, so a second email was sent to info@... and also to the Microsec contact persons CCADB.
Due to the delay, 3 separate incident reports was created as follows:

The current bug focuses on the delayed revocation (Bug #2).

Impact

The missing CPSuri information has no impact on the usability or security of the certificate, but it makes it more difficult for users to find the policy information.
The reported misissued certificate is:
https://crt.sh/?id=12302329269

Timeline

  • Bug #3 deals with the incident why Microsec did not answered for the first email on time.
  • In this incident we calculate the 5 days deadline based on the receiving time of the second email.
  • The timing is described in detail in the other two incident reports, here we repeat only those that are important to this bug.

2024-03-07

  • Microsec received an email to the general purpose email address info@... provided in CCADB reporting a potentially misissued certificate.
    • one misissued EV certificate was reported based on random tests

2024-03-18

  • 13:06 UTC (14:06 CET)
    • Microsec received a second email to the general purpose email address info@... provided in CCADB reporting a potentially misissued certificate. This second email was also sent directly to the contact persons of Microsec provided in CCADB.
      • Bug #1 deals with the basic process in details, here we list only the main points
  • 16:15 UTC (17:15 CET)
    • Microsec modified all (7) problematic EV TLS certificate profiles
  • 17:03 UTC
  • 17:05 UTC
    • The misissued certificate was revoked.
      • the reported certificate was revoked within 4 hours after receiving the second email

2024-03-19

  • 11:00 UTC (12:00 CET)
    • Microsec discovered that a total of 45 EV TLS certificates have been misissued with the same problem since 2023-08-29
    • These misissued certificates shall be revoked within 5 days in accordance with CABF BR requirements, deadline is 2024-03-24 12:00
  • 16:00 UTC (17:00 CET)
    • Microsec issued 44 of 45 infected certificates, one had a CAA issue

2024-03-21

  • One PSD2 service provider reported that it is not possible to replace the certificate in the whole network within 5 days and asked the extension of the deadline
  • Microsec contacted the Root Program operators asking for extension for this specific customer

2024-03-22

  • Microsec issued the 45th affected EV certificate
  • Another PSD2 service provider reported that it is not possible to replace the certificate in the whole network within 5 days and asked the extension of the deadline
  • Based on the risk analysis and responses received from Root Programs, Microsec extended the revocation deadline exclusively for these two PSD2 certificates until 2024-04-09 12:00

Root Cause Analysis

  • There is a special type of certificate, called PSD2 QWAC, that can also meet EVG requirements.
    These certificates are not used for website authentication, so in practice they never cause problems in the operation of web browsers, but theoretically they can be used for this purpose, when issued under a Root CA that is trusted by any of the Root Programs.

  • PSD2 certificates are used to secure connections between servers in financial services, as a client or server authentication certificate. A server can be connected to hundreds or even thousands of partners, such as banks or other financial service providers. In current solutions, the PSD2 QWAC certificate is propagated and trusted by each parties.
    In many cases this propagation cannot be done automatically, but is a manual process that takes time.
    Changing a PSD2 QWAC certificate typically takes weeks on large networks, it definitely cannot be done in a few days.
    Early revocation of a misissued PSD2 QWAC certificate would result in a financial service interruption, resulting in potential losses and customer claims.

  • It is a general problem of this PSD2 system solution, which PSD2 service providers should solve in the future by developing automation or using another trust model.
    In the event of a potential critical security issue with a PSD2 QWAC certificate, it shall be revoked within 24 hours, which would block these financial services.
    This problem cannot be solved now in this project.

  • In our case the problem is the lack of CPSuri information in the certificate, which has no impact on the security in the use of the certificate.
    Extending the revocation deadline is much smaller problem than revoking the certificate in time and blocking these financial services.

Lessons Learned

  • Current PSD2 systems cannot always respond quickly for potential incidents related to PSD2 QWAC / EV certificates.
    It can have serious consequences in case of a critical certificate issue.

What went well

  • All affected EV certificates have been easily issued as a technical certificate modification.
    New certificates have the same validity end time as the corresponding misissued certificates.
  • Only one certificate had CAA issues, but it was resolved in time

What didn't go well

  • For PSD2 QWAC EV certificates, PSD2 service providers cannot meet the 5-day deadline in case of large networks

Where we got lucky

Action Items

Action Item Kind Due Date
Revoking 43 misissued certificates Repair 2024-03-24
Revoking the 2 misissued PSD2 certificates Repair 2024-04-09
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31

Appendix

Details of affected certificates

There are 45 misissued certificates, the full list is published in Bug #1

The following two certificates are involved in late revocation:

Misissued certificate (or precertificate) New certificate (or precertificate)
https://crt.sh/?id=10727629590 https://crt.sh/?id=12436572004
https://crt.sh/?id=12240328933 https://crt.sh/?id=12436805621

Based on Incident Reporting Template v. 2.0

Assignee: nobody → szoke.sandor
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [leaf-revocation-delay]

Incident Status Report - 2024-04-05

Timeline

2024-03-24

Action Items

Action Item Kind Due Date Status
Revoking 44 misissued certificates Repair 2024-03-24 Done
Revoking 2 misissued PSD2 certificates Repair 2024-04-09 Scheduled
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31 Planned

Incident Status Report - 2024-04-09

Timeline

2024-04-09

  • 2 misissued PSD2 certificates revoked
  • revocation of misissued certificates finished

Action Items

Action Item Kind Due Date Status
Revoking 44 misissued certificates Repair 2024-03-24 Done
Revoking 2 misissued PSD2 certificates Repair 2024-04-09 Done
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31 Started

Appendix

Details of affected certificates

Misissued certificate (or precertificate) Revocation time / OCSP answer
https://crt.sh/?id=10727629590 2024-04-09 12:08:03 UTC
https://crt.sh/?id=12240328933 2024-04-09 12:58:03 UTC
Whiteboard: [ca-compliance] [leaf-revocation-delay] → [ca-compliance] [leaf-revocation-delay] Next update 2024-05-31

What is Microsec doing to ensure that it does not issue certificates to systems that cannot tolerate the revocation schedule that Microsec has committed to as part of the BRs?

Why are PSD2 systems using WebPKI, if those systems cannot meet the BR revocation requirements?

Was Microsec aware, when they issued these certificates, that the certificates were going to be used in a critical environment that could not accommodate the revocation schedule set forth in the BRs? If so, why did Microsec choose to issue certificates for that use? If not, how will Microsec ensure that its certificates are not used for services which are so critical that their inability to rotate certificates would again lead Microsec to violate its commitment to the root programs?

Flags: needinfo?(szoke.sandor)

Answer to Mike Shaver - 2024-05-23

  • What is Microsec doing to ensure that it does not issue certificates to systems that cannot tolerate the revocation schedule that Microsec has committed to as part of the BRs?

    • Microsec is committed to fully complying with the requirements of Root Programs, and expects this from its partners as well, deviating from this only in extremely justified cases.
    • The present incident showed us that the server authentication certificates in PSD2 systems are not always used in accordance with best practices, and because of this, they are not always able to fully meet the BR requirements.
    • We learned from this incident that in the future we should specifically draw the attention of special customers to these revocation requirements and only issue certificates to customers who can meet these requirements.

  • Why are PSD2 systems using WebPKI, if those systems cannot meet the BR revocation requirements?

    • The ETSI TS 119 495 specification (https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.06.01_60/ts_119495v010601p.pdf) requires the use of QWAC to establish the secure communication channel between financial service providers in PSD2 systems, and it is also preferred by the opinion issued by EBA (European Banking Authority) see: https://www.eba.europa.eu/sites/default/files/documents/10180/2137845/d429d45e-f936-473c-bc02-c23060d11f19/EBA%20Opinion%20on%20the%20use%20of%20eIDAS%20certificates%20under%20the%20RTS%20on%20SCACSC.pdf in section 14.
    • as far as we know, most PSD2 service providers work according to section 14./a of the EBA document
    • in our opinion, the main problem is not the use of the QWAC PSD2 certificate, but the way it is used
      • a service provider may be connected to hundreds or thousands of other service providers
      • each communication channel uses TLS protection, based on PSD2 QWAC server authentication or/and client authentication certificates
      • each service provider has its own PSD2 QWAC certificate, which has to be accepted by each partner service provider
      • the problem is that in many cases service providers hardcode their partner's QWAC certificate into their system instead of using standardised validation solutions which are not tigth to a specific certificate
      • this hard-coded solution typically requires changing the configuration for each partner, which is a time-consuming task due to the sensitive area of use and the large number of partners

  • Was Microsec aware, when they issued these certificates, that the certificates were going to be used in a critical environment that could not accommodate the revocation schedule set forth in the BRs?

    • Microsec was aware that these certificates would be used in a critical system, but did not know that validation was done this way, and that in the event of an incident, certificate replacement would not be possible within 5 days.
      • If not, how will Microsec ensure that its certificates are not used for services which are so critical that their inability to rotate certificates would again lead Microsec to violate its commitment to the root programs?
        • Microsec plans to offer an alternative certificate type to its PSD2 customers that is not covered by the TLS BR.
        • Microsec strongly draws the attention of customers requesting PSD2 certification to this requirement
        • Microsec will issue PSD2 QWAC certificates only for those PSD2 users, who will tolerate the revocation of a misissued certificate within maximum 5 calendar days in case of an incident (in practice it means less than 5 calendar days for the partners, because Microsec also needs time to process the incident report, and inform the partners about the necessary revocation).

Further actions

  • Microsec is presently still working on this issue and will give a status report next week before the promised deadline, which will contain more detailed information.

Action Items

Action Item Kind Due Date Status
Revoking 44 misissued certificates Repair 2024-03-24 Done
Revoking 2 misissued PSD2 certificates Repair 2024-04-09 Done
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31 In progress
Flags: needinfo?(szoke.sandor)

I'm afraid you have not been interpreting the ETSI TS 119 495 and the latest EN 319 411-2 accurately.

It has always been possible to issue PSD2 QWACs that deviate from the CA/B Forum BRs and are not trusted by Browsers.

Thank you for your response!

Dimitris, you are absolutely right, it is possible to issue PSD2 QWAC certificates, which are not within the scope of CABF BR. To do this, we need to issue the certificate under a root CA that is not trusted by any of the root programs.
This solution was also within the scope of our research, but we currently do not plan to issue those types of certificates.

More details will come next week.

Incident Status Report - 2024-05-31

Possible solutions

During the investigation, Microsec analysed a number of possibilities, here we only briefly summarize those that have some possibility of being introduced at least in the medium term. These are the followings:

  • Changing the use of PSD2 QWAC certificates in PSD2 networks
  • Issuance of PSD2 QWAC certificates independent of webPKI
  • Modification of PSD2 QWAC certificate profiles
  • Only issue PSD2 QWAC certificates to users who undertake full compliance with CABF requirements

Changing the use of PSD2 QWAC certificates in PSD2 networks

Financial institutions and financial information service providers in PSD2 systems use a wide range of technical solutions to establish secure communications with their partners.
When establishing the secure communication channel with a partner, the service provider shall validate both the PSD2 certificate and the partner.

  • PSD2 certificates contain standardised information in the QCStatement extension about the service provider, its PSD2 role and its Competent Authority, so all relevant data needed to set up the secure channel can be retrieved from the PSD2 certificate. It would be preferable to retrieve this information directly from the partner's PSD2 QWAC certificate when establishing a new connection.
  • To validate the PSD2 certificate, partners shall also validate the issuer of the PSD2 QWAC certificate, which can have the following options:
    • can be based on the trusted root stores maintained by operating system or/and browser providers
    • trust can be based on EU Trust Lists, so a PSD2 QWAC certificate can be trusted if it is issued by a Qualified TSP that is listed on one of the national Trust List
    • PSD2 partners can set up and maintain their own whitelist, which includes TSPs they consider trustworthy.

Using the above solution, trust would not be based on a specific certificate, but in a more general way, on authentic data contained in PSD2 certificates.
This solution would not require the change in the configuration of each partner in case of replacing the PSD2 certificate for any reason.
It would also easily support the use of short-life certificates, because the PSD2 certificate needs to be renewed only at a single point in the network, which can be done easily or even automatically.

The problems with this solution are,

  • It is currently not supported by a large portion of PSD2 service providers.
  • Financial institutions are usually very conservative, they have strict rules about how to make changes to their IT systems, and each change takes a lot of time.
  • there is no standard solution or system, partners use their own specific systems
  • due to the large number of partners, a large number of different systems need to be upgraded

Due to these limitations we do not expect to achieve big progress in this field in the short term.

We can provide information or technical help to our partners in this area, but anyhow it would be a long-range project and cannot solve our problems right now.

Issuance of PSD2 QWAC certificates independent of webPKI

PSD2 QWAC certificates are used to secure point to point connections and are not used in webPKI at all.
In accordance with the current ETSI requirements, it is possible to issue PSD2 QWAC certificates, which are deviate from webPKI and do not depend on browser manufacturers.

  • the PSD2 QWAC certificate shall be issued under a root CA that is not trusted by any Root Program
  • ETSI EN 319 411-2 defines special certificate profile QNCP-w-gen for this purpose, where not all CABF BR requirements need to be met

We discussed this possibility with our customers. They don't like this solution because they use standard applications to establish the TLS connection, so they prefer certificates that are also trusted by the Root Programs.

Microsec does not currently have a separate CA hierarchy and, based on this survey, does not plan to establish a separate root for this purpose in the near future.
This situation may change later, but currently Microsec cannot and does not plan to issue PSD2 QWAC certificates of this type.

Modification of PSD2 QWAC certificate profiles

Our previous PSD2 QWAC certificates included both serverAuth and clientAuth EKU values.
In a large number of communication partners, this certificate was somehow hardwired into the program, or better case, into a configuration file.
As a result, in case of certificate replacement, this certificate had to be updated not only in one place, as expected, but at many partners in the PSD2 network, which can mean hundreds or even thousands of places.

Microsec has decided to split this multi-purpose PSD2 QWAC certificate into two different certificates and instead of the previous single PSD2 QWAC certificate, it issues two PSD2 QWAC authentication certificates in the PSD2 service package as follows:

  • PSD2 QWAC server authentication certificate, which is fully compatible with CABF BR and EVG and contains only the serverAuth EKU value.
    This certificate will be managed in accordance with CABF requirements, including revocation within a given timeframe in case of misissuance or any issues listed in CABF BR and/or EVG.
    Microsec recommends using this certificate only for those connections where the quick replacement of the certificate will not cause problems.
  • PSD2 (QWAC) client authentication certificate will include only the clientAuth EKU and will be issued by a non TLS subordinate CA, that way being independent of the Root Program requirements.
    This certificate will contain the same PSD2 QCStatement information, so it will be usable to establish the secure TLS connection as a client.
    The replacement of this certificate may not be so critical, so customers may have longer window for regular or unexpected upgrades.
    Microsec strongly recommends using this certificate on every connection where possible.

This change has already been made, existing customers are notified about this change during the normal renewal process.

Our web application pages will be updated soon and new PSD2 customers will automatically receive 3 certificates in one package.

Issuing PSD2 QWAC certificates only to those users who undertake full compliance with CABF requirements

Microsec will add further information into its CPS document in the next release, scheduled for August 2024.

  • It will contain the revocation deadline for each revocation reason, in accordance with CABF BR.
  • It will also contain a clear obligation to the customer, that they are responsible how they use the issued TLS certificate.
    The use of TLS certificate is not recommended in critical infrastructure, where the lack of valid certificate may cause serious financial loss or interruption of any critical services.
  • It will be clearly stated, that Microsec will never allow extension of revocation deadlines.

TLS certificates will be issued only to those customers who accept these conditions.

Until the release of the new version of CPS, Microsec continues to inform its partners about these changes directly during the renewal process.

Action Items

Action Item Kind Due Date Status
Revoking 44 misissued certificates Repair 2024-03-24 Done
Revoking 2 misissued PSD2 certificates Repair 2024-04-09 Done
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31 Done

(In reply to dr. Sándor SZŐKE from comment #9)

Dimitris, you are absolutely right, it is possible to issue PSD2 QWAC certificates, which are not within the scope of CABF BR. To do this, we need to issue the certificate under a root CA that is not trusted by any of the root programs.

Thanks for the update. This is a very interesting issue to clarify. I'm wondering if it is possible to issue a Subordinate CA Certificate that is policy restricted by not including any of the CA/B Forum reserved Policy OIDs in the TLS BRs, allowing you to issue PSD2 Certificates that are not 100% compatible with the TLS BRs.

Publicly-Trusted Root (in scope of the BRs) --> Intermediate CA Certificate (EKU:id-kp-serverAuth, certificatePolicies: non-BR OIDs) --> Leaf Certificate (EKU:id-kp-serverAuth, certificatePolicies: ETSI EN 319 411-2 QNCP-w-gen, and/or any other non-BR OIDs).

Based on the RFC 5280 path building algorithm, the final validation will not include any of the CA/B Forum policy OIDs so Relying Parties will know that these are not BR-compliant certificates.

I'm curious what people think, and especially Root Program managers.

(In reply to Dimitris Zacharopoulos from comment #11)

Publicly-Trusted Root (in scope of the BRs) --> Intermediate CA Certificate (EKU:id-kp-serverAuth, certificatePolicies: non-BR OIDs) --> Leaf Certificate (EKU:id-kp-serverAuth, certificatePolicies: ETSI EN 319 411-2 QNCP-w-gen, and/or any other non-BR OIDs).

I'd say the BR's do not allow this. While the Subordiante CA itself wouldn't assert compliance with the BRs, that in and of itself would constitute a misissuance by the Root CA.

Presuming the Root CA to be in scope of the BRs, any Subordinate CA capable of issuing TLS Certificates issued by that Root CA must comply with Section 7.1.2.6 (or 7.1.2.5) of the TLS BRs. There's a requirement for either the anyPolicy or one or more of the Reserved Certificate Policy Identifiers to be included within the Subordinate CA.

As such, in your example I would state the Intermediate CA (Subordinate CA) should be deemed misissued

(In reply to Martijn Katerbarg from comment #12)

(In reply to Dimitris Zacharopoulos from comment #11)

Publicly-Trusted Root (in scope of the BRs) --> Intermediate CA Certificate (EKU:id-kp-serverAuth, certificatePolicies: non-BR OIDs) --> Leaf Certificate (EKU:id-kp-serverAuth, certificatePolicies: ETSI EN 319 411-2 QNCP-w-gen, and/or any other non-BR OIDs).

I agree that it is not possible in the case of a Publicly-Trusted Root, but in my interpretation, the CABF BR requirements do not address Certificates,
"for which the Root Certificate is not distributed by any Application Software Supplier."

I would like to see your opinion regarding this, but in any case I confirm that Microsec does not plan to issue this type of PSD2 certificates. Microsec issues such PSD2 QWAC certificates that are also CABF BR and EVG compliant, and the corresponding CABF OID will be included in the certificates.

(In reply to Martijn Katerbarg from comment #12)

(In reply to Dimitris Zacharopoulos from comment #11)

Publicly-Trusted Root (in scope of the BRs) --> Intermediate CA Certificate (EKU:id-kp-serverAuth, certificatePolicies: non-BR OIDs) --> Leaf Certificate (EKU:id-kp-serverAuth, certificatePolicies: ETSI EN 319 411-2 QNCP-w-gen, and/or any other non-BR OIDs).

I'd say the BR's do not allow this. While the Subordiante CA itself wouldn't assert compliance with the BRs, that in and of itself would constitute a misissuance by the Root CA.

Presuming the Root CA to be in scope of the BRs, any Subordinate CA capable of issuing TLS Certificates issued by that Root CA must comply with Section 7.1.2.6 (or 7.1.2.5) of the TLS BRs. There's a requirement for either the anyPolicy or one or more of the Reserved Certificate Policy Identifiers to be included within the Subordinate CA.

As such, in your example I would state the Intermediate CA (Subordinate CA) should be deemed misissued

I took a deeper look at 7.1.2.10.5 and I agree that this is not allowed for the Subordinate TLS CA profile. Even if the "anyPolicy" was used, it would still not be allowed to issue a leaf certificate that does not contain one of the reserved CA/B Forum policy OID.

On the one hand the CA/B Forum allows the creation of Technically Constrained non-TLS Subordinate CAs from in-scope Root hierarchies but it does not allow non-BR-TLS Subordinate CAs. I'm not sure if this is a feature or a bug but perhaps this should be clarified in the CA/B Forum SCWG and not on this bug.

Agreed that this bug is not the right venue, but in my opinion that's definitely a feature. If it was allowed to create non-BR TLS Subordinate CAs, why wouldn't every CA do that for all of their certificates and avoid having to comply with the BRs entirely? The point of Technically Constrained hierarchies is that if something goes wrong, the "blast radius" is limited. Being able to simply say "these certs are valid TLS certs but they don't have to comply with the BRs" obviates the whole purpose of the BRs.

(In reply to dr. Sándor SZŐKE from comment #10)

Microsec has decided to split this multi-purpose PSD2 QWAC certificate into two different certificates and instead of the previous single PSD2 QWAC certificate, it issues two PSD2 QWAC authentication certificates in the PSD2 service package as follows:

  • PSD2 QWAC server authentication certificate, which is fully compatible with CABF BR and EVG and contains only the serverAuth EKU value.
    This certificate will be managed in accordance with CABF requirements, including revocation within a given timeframe in case of misissuance or any issues listed in CABF BR and/or EVG.
    Microsec recommends using this certificate only for those connections where the quick replacement of the certificate will not cause problems.
  • PSD2 (QWAC) client authentication certificate will include only the clientAuth EKU and will be issued by a non TLS subordinate CA, that way being independent of the Root Program requirements.
    This certificate will contain the same PSD2 QCStatement information, so it will be usable to establish the secure TLS connection as a client.
    The replacement of this certificate may not be so critical, so customers may have longer window for regular or unexpected upgrades.
    Microsec strongly recommends using this certificate on every connection where possible.

This change has already been made, existing customers are notified about this change during the normal renewal process.

Our web application pages will be updated soon and new PSD2 customers will automatically receive 3 certificates in one package.

This approach seems to be contrary to the direction that root stores want to move towards. For example, from Chrome Root Program Policy, Version 1.5:

The Chrome Root Program will only accept CCADB “Root Inclusion Requests” from Applicant PKI hierarchies that are dedicated to TLS server authentication certificate issuance.

A dedicated PKI hierarchy is intended to serve one specific use case, for example, the issuance of TLS server authentication certificates.

To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:

  1. All corresponding subordinate CA certificates operated beneath a root CA MUST:
    • include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:
      1. id-kp-serverAuth, or
      2. id-kp-serverAuth and id-kp-clientAuth
    • NOT contain a public key corresponding to any other unexpired or non-revoked certificate that asserts different extendedKeyUsage values.
  2. All corresponding subscriber (i.e., server) certificates MUST:
    • include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:
      1. id-kp-serverAuth, or
      2. id-kp-serverAuth and id-kp-clientAuth

(In reply to Mathew Hodson from comment #16)

(In reply to dr. Sándor SZŐKE from comment #10)

This approach seems to be contrary to the direction that root stores want to move towards. For example, from Chrome Root Program Policy, Version 1.5:

it is possible that our description of the PSD2 client authentication certificate was incomplete or misleading, so I will provide more details about it.

  • Our PSD2 client authentication certificate does not contain serverAuth EKU and does not contain any FQDN or IP address, so it is not in the scope of CABF BR.
  • The subject and PSD2 QCStatement information are mainly the same as for the PSD2 QSeal certificate, which is used by financial service providers to digitally sign messages in the PSD2 system.
  • Currently, Microsec operates multifunctional roots and the different types of end-user certificates are issued from dedicated subordinate CAs. PSD2 authentication certificates are issued from a subCA that is never used to issue TLS certificates.

Microsec is aware of the Chrome Root Program requirements, which relate to the new "Root Inclusion Requests".
To meet this requirement, Microsec created a dedicated CA hierarchy in 2023 that will be used exclusively to issue TLS certificates.
This new TLS hierarchy successcully passed the annual conformity assessment in Q4 2023, and the new CAs are already included in CCADB, see here: e-Szigno TLS Root CA 2023
Our new Root is already trusted by Microsoft, and we applied for inclusion in Apple, Mozilla ang Google root programs in January 2024.
Once these root programs trust this new root, Microsec switches the issuance of TLS certificates to this dedicated TLS CA hierarchy.

(In reply to dr. Sándor SZŐKE from comment #0)

Changing a PSD2 QWAC certificate typically takes weeks on large networks, it definitely cannot be done in a few days.

In fact, it can. You will see in Sectigo’s recent bug 1897538 that we revoked two misissued PSD2 QWACs within 120 hours. Though the bug doesn’t state it, I can tell you there was no service interruption from this on-time revocation.

In your Incident Report you state in two places that Subscribers told you, if I may paraphrase, they would not be able to change out these certificates on time and that the consequences would be disastrous. This is pretty much the standard response whenever Subscribers are given a revocation deadline. However, when CAs hold the line on these deadlines, it turns out Subscribers are able to swap in new certificates after all.
Please read what I said on bug 1896553 comment 7. While this comment is on a different delayed revocation bug for a different CA, what I said there is highly relevant here as well. When CAs do not enforce revocation timelines, these timelines become meaningless.

When I review your action items, in this comment and later in this bug, I don’t see anything to address the root cause of this incident, which is Microsec’s failure to honor the BR-mandated revocation timeline. Can you please provide one or more action items to address this problem?

(In reply to Tim Callan from comment #18)

(In reply to dr. Sándor SZŐKE from comment #0)

Changing a PSD2 QWAC certificate typically takes weeks on large networks, it definitely cannot be done in a few days.

I will study your comments and the referenced bugs and will provide our answers soon.

(In reply to dr. Sándor SZŐKE from comment #10)

  • Financial institutions are usually very conservative, they have strict rules about how to make changes to their IT systems, and each change takes a lot of time.

Keep the cake

We discussed this possibility with our customers. They don't like this solution because they use standard applications to establish the TLS connection, so they prefer certificates that are also trusted by the Root Programs.

Eat the cake.

I believe that it is a good decision you have made to make sure that if a subscriber wants to leverage the benefits of webPKI certificates then they also need to take on the responsibilities that entails.

(In reply to Tim Callan from comment #18)

(In reply to dr. Sándor SZŐKE from comment #0)

Changing a PSD2 QWAC certificate typically takes weeks on large networks, it definitely cannot be done in a few days.

You're right, my wording was inaccurate. Of course, anything is possible if you have the right resources.
Microsec is able to revoke all misissued certificates and issue replacement certificates within the time frame established by CABF BR.
In our incident there were 46 misissued EV certificates and 44 of them were replaced and revoked within the expected time frame.
It also included some PSD2 QWAC certificates. They were probably used in smaller networks or their operators had better control of their network.

2 of our customers contacted us and asked for an extension of the 5-day deadline.
They told us that they used the PSD2 QWAC certificate as a client certificate in a huge PSD2 network consisting of more than 1000 partners.
It is not enough to replace the PSD2 client authentication certificate on their premises, but they must also contact all their partners and ask them to replace this client authentication certificate on their system.
This process usually takes a month and they are not able to speed it up significantly.
I'm not saying it's not possible, I'am just saying that's what we've been told, and of course we are not able to verify that statement.
We had an urgent online meeting with this customer and they confirmed that they would not be able to do it within a few days and that revocation would cause a major disruption to their service.

We understand that the extension of the revocation deadline violates the rules established in CABF BR and we did not want to make this decision ourselves. Before making this decision, we contacted the main browser vendors (Apple, Google, Microsoft, Mozilla) by email, we described this problem to them and requested an extension of the deadline from 5 days only for these 2 certificate to 21 days.
We received quick responses. One vendor explicitly allowed the applied deadline extension, others responded that they do not require us to cause serious problems to our customers, but we had to analyze the situtation and make the decision. In case of violation of the CABF BR rules, we had to write our reasons and actions in the public incident reports.

Based on the responses received and the nature of the problem, we finally decided to extend the deadline only for these two certificates.
We opened incident bugs to explain the situation and actions.

We consider this case as an only exception in our practice, and decided to be absolutely strict with similar requirements in the future.
Details can be read in Comment 10.

Action Items

For an easier overview, we added the most important changes to our actions list:

Action Item Kind Due Date Status
Revoking 44 misissued certificates Repair 2024-03-24 Done
Revoking 2 misissued PSD2 certificates Repair 2024-04-09 Done
Studying our possibilities how to issue less sensitive certificates to PSD2 customers Prevent 2024-05-31 Done
Stop issuing combined client/server authentication TLS certificates Prevent 2024-05-31 Done
Offer a non TLS based PSD2 client authentication certificate Prevent 2024-05-31 Done
Inform our partners not to tolerate any excuse regarding unability to replace certificates within the required timeframe Prevent 2024-05-31 Started, In progress
Upgrade our CPS to make the revocation requirements more clear including strict deadlines Prevent 2024-08-31 Planned
Whiteboard: [ca-compliance] [leaf-revocation-delay] Next update 2024-05-31 → [ca-compliance] [leaf-revocation-delay]
You need to log in before you can comment on or make changes to this bug.