Closed Bug 1815355 Opened 1 year ago Closed 11 months ago

Asseco DS / Certum: Cross-Signed non-EV-audited root with an EV-enabled root

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: aleksandra.kurosz)

Details

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

I was just looking at crt.sh/mozilla-disclosures#disclosureincomplete

The SSL.com certs that are listed chain up to a cross-signed certificate that is signed by an EV-enabled root certificate from Asseco DS / Certum. So, the Asseco DS / Certum CA has enabled a bunch of certificates for EV TLS that do not have EV TLS audits.

Issuer CN: E-Tugra TLS ECC CA R1
signed by SSL.com Root Certification Authority ECC -- not EV enabled
and that has a doppelganger that is signed by SSL.com Root Certification Authority RSA -- not EV enabled
and that has a doppelganger that is signed by Certum Trusted Network CA -- EV enabled

Issuer CN: SSL.com SSL Enterprise Intermediate CA RSA R1
signed by SSL.com Root Certification Authority RSA -- not EV enabled
and that has a doppelganger that is signed by Certum Trusted Network CA -- EV enabled

Issuer CN: SSL.com Root Certification Authority ECC
signed by SSL.com Root Certification Authority RSA -- not EV enabled
and that has a doppelganger that is signed by Certum Trusted Network CA -- EV enabled

Issuer CN: SSL.com Root Certification Authority RSA
has a doppelganger that is signed by Certum Trusted Network CA -- EV enabled

Thank you for your report, we will check it and come back with an analysis

Assignee: nobody → aleksandra.kurosz
Whiteboard: [ca-compliance] → [ca-compliance] [ca-misissuance]

Hi Aleksandra,
While you are looking at them, also check for the "AnyPolicy" Policy OID and compliance with section 7.1.6.3 of the Baseline Requirements and section 9.3.4 of the EV Guidelines.
Thanks,
Ben

Flags: needinfo?(aleksandra.kurosz)
Status: NEW → ASSIGNED
  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We became aware of the problem from this bug created on 07.02.2023.

  1. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

11.09.2018 - Certum issues a cross-certificate “Root Certification Authority RSA” (SHA256 Fingerprint ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B) for SSL Corporation “Root CA SSL.com Root Certification Authority RSA” (SHA256 Fingerprint 85666A562EE0BE5CE925C1D8890A6F76A87EC16D4D7D5F29EA7419CF20123B69).

07.02.2023 - The bug https://bugzilla.mozilla.org/show_bug.cgi?id=1815355 is created.

07-14.02.2023 - Certum analyzes the problem: checks internal documentation, checks Sub CAs, checks end entity certificates issued from these Sub CAs and other aspects of this case that will be helpful in clarifying the situation. Certum also contacts SSL Corporation in order to confirm the findings.

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Certum issues cross-certificates only when they are preceded by a detailed analysis (described below). Until the reported problem is resolved, Certum will not issue any new cross-certificate

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

A problematic certificate was issued on 11.09.2018.

  1. The complete certificate data for the problematic certificates.

https://crt.sh/?sha256=ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

At the time when the decision to issue a cross-certificate to SSL Corporation was made, we were aware that their SSL Corporation Root CA “Root Certification Authority RSA” (SHA256 Fingerprint 85666A562EE0BE5CE925C1D8890A6F76A87EC16D4D7D5F29EA7419CF20123B69) was not ev enabled, but we also knew that SSL Corporation policy did not allow the issuance of EV SSL certificates from the certification path of that Root CA. At the time, all of our Root CAs were ev enabled, so we were not technically able to protect against extending trust to SSL EV certificates. However, given the SSL Corporation's policy for this Root CA and the relevant provisions in the contract, we decided to issue this cross-certificate.

During the validity period of this cross-certificate, we continuously monitored the issued certificates in public databases such as crt.sh and Censys. In addition, we have confirmed with SSL Corporation that no EV SSL certificate was issued from the certification path of this Root CA.

SSL Corporation Root CA “Root Certification Authority RSA” (SHA256 Fingerprint 85666A562EE0BE5CE925C1D8890A6F76A87EC16D4D7D5F29EA7419CF20123B69) is in the 2019 WebTrust EV SSL SSL Corporation audit. This is an audit report covering the period July 1, 2018 to June 30, 2019. This is the first audit report after the cross-certificate was generated.

All Sub CAs listed in the bug have the value anyPolicy in the Certificate Policies extension, which per BR and is allowed only the Sub CA entity is an affiliate of the issuer. The private keys for all Sub CAs listed in the bug are under the exclusive control of SSL Corporation, so from their perspective they are affiliate Sub CAs. In other words, these SUB CAs are controlled by the Root CA of SSL Corporation.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Before issuing a cross-certificate, we carry out a thorough analysis of the potential entity for which it would be issued. Our policy only allows cross-certificates to be issued to fully operational CAs. The main steps we perform during the analysis are:

  • verification of the organisation of the intended CA entity,

  • verification of the intended CA's WebTrust audit reports,

  • verification of membership status in the trusted browsing programmes of the intended CA,

  • verification and assessment of the intended CA's CP/CPS compliance against Certum's CP/CPS,

  • verification of the membership status in CA/Browser Forum,

  • verification of the Root CA certificate of the intended CA subject,

  • verification of the use case that cross-certificate intends to serve,

  • verification of the contract to be signed with the intended CA.

After collecting all the required documents and carrying out the necessary verifications, the compliance team prepares a report for the management board. This report contains all the necessary information and takes into account potential risks. The management board, after reviewing the report and discussion with the compliance team, makes the final cross-certification decision.

Our first priority when deciding to cross-certify another entity is not to expose end-users to additional risks. We believe that we mitigate any risks through this multi-step process.

Flags: needinfo?(aleksandra.kurosz)

Aleksandra, please...

  1. Provide all of the EV SSL audits for all of the subordinate CA certificates that this cross-signing enabled for EV treatment.
  • E-Tugra TLS ECC CA R1
  • SSL.com SSL Enterprise Intermediate CA RSA R1
  • SSL.com Root Certification Authority ECC
  • SSL.com Root Certification Authority RSA

Reminder of Mozilla's Root Store Policy:

  • An audit showing conformance with the EVCP policy is REQUIRED if a CA is capable of issuing EV certificates.
  • Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually ... Successive period-of-time audits MUST be contiguous (no gaps).
  1. Explain why your CA did not restrict the Policy OIDs in the cross-certificate, so that it would not be EV-enabled.

Reference: https://wiki.mozilla.org/CA/EV_Processing_for_CAs

  1. Provide a timeline for when you will replace the existing cross-certificate (and revoke it) with a cross-certificate that restricts its Policy OIDs so that it is not EV-enabled.
Flags: needinfo?(aleksandra.kurosz)
  1. Provide all of the EV SSL audits for all of the subordinate CA certificates that this cross-signing enabled for EV treatment.

E-Tugra TLS ECC CA R1 (108162F2B35ED71C6EA9502F94B93E9754789DDE871B2AC26CE06D47207A95CC) - not in the current WT SSL EV report

SSL.com SSL Enterprise Intermediate CA RSA R1 (EDAC9C45909F4DEC7BB65F0A4FBF6A8A0375E52AEDD66E06888FED7E3EDEC537) - not in current WT SSL EV report

SSL.com Root Certification Authority ECC (3417BB06CC6007DA1B961C920B8AB4CE3FAD820E4AA30B9ACBC4A74EBDCEBC65) - is in the current WT SSL EV report

SSL.com Root Certification Authority RSA (85666A562EE0BE5CE925C1D8890A6F76A87EC16D4D7D5F29EA7419CF20123B69) - is in the current WT SSL EV report

  1. Explain why your CA did not restrict the Policy OIDs in the cross-certificate, so that it would not be EV-enabled.

As we explained earlier, we assumed it was sufficient that the SSL Corporation Root CA was not ev enabled, but the SSL Corporation policy did not allow EV SSL certificates to be issued from this root CA's certification path. At that time, as we see now, we mistakenly believed that this was sufficient security. It was in 2018, when both our awareness and browser policies were different, we obviously wouldn't do it the same way today given the current cross certificate regulations and our awareness. Currently, before issuing each cross certificate, we perform a detailed analysis and such an incorrect issue will not occur again.

  1. Provide a timeline for when you will replace the existing cross-certificate (and revoke it) with a cross-certificate that restricts its Policy OIDs so that it is not EV-enabled.

We have contacted SSL.COM and will provide an action plan as soon as possible.

We have been monitoring this conversation closely and communicating with Asseco DS/Certum CA regarding this matter. We would like to contribute to this bug with some additional information for increased transparency.

SSL.com has four Root CA Certificates enabled with the websites trust bit in the Mozilla Root Store:

  1. SSL.com Root Certification Authority RSA (serial: 7B2C9BD316803299)
  2. SSL.com Root Certification Authority ECC (serial: 75E6DFCBC1685BA8)
  3. SSL.com EV Root Certification Authority RSA R2 (serial: 56B629CD34BC78F6)
  4. SSL.com EV Root Certification Authority ECC (serial: 2C299C5B16ED0595)

Out of these four included Root CA Certificates, only the last two are enabled for EV treatment.

Asseco DS / Certum has issued two cross-certificates:

  1. Issuer: Certum Trusted Network CA --> Subject: SSL.com Root Certification Authority RSA (crt.sh ID: 759010256)
  2. Issuer: Certum Trusted Network CA --> Subject: SSL.com EV Root Certification Authority RSA R2 (crt.sh ID: 759010264)

SSL.com has issued two additional cross-certificates:

  1. Issuer: SSL.com Root Certification Authority RSA --> Subject: SSL.com Root Certification Authority ECC (crt.sh ID: 1220120832)
  2. Issuer: SSL.com EV Root Certification Authority RSA R2 --> Subject: SSL.com EV Root Certification Authority ECC (crt.sh ID: 1220121486)

As explained in Comment 3, SSL.com and Certum have had a cross-signing agreement since September 2018. In this agreement, SSL.com committed to issuing EV TLS Certificates from its “EV-enabled” hierarchy, chaining to either “SSL.com EV Root Certification Authority RSA R2” or “SSL.com EV Root Certification Authority ECC” independently included Roots.

SSL.com has fulfilled this obligation which can be demonstrated by the following:

• The issuance of an EV TLS Certificate from the non-EV hierarchies would be detected and considered a mis-issuance, flagged in annual audit reports.
• Searching CT logs proves that no EV-enabled policy OID has been included in end-entity certificates issued from the non-EV hierarchies.

SSL.com is CT logging all issued end-entity certificates. These are the queries using censys.io which prove that no EV-enabled TLS Certificate has been issued from the non-EV hierarchies:

• https://search.censys.io/certificates?q=parsed.extensions.certificate_policies.id%3A+2.23.140.1.1+and+validation.nss.paths%3A+85666a562ee0be5ce925c1d8890a6f76a87ec16d4d7d5f29ea7419cf20123b69
• https://search.censys.io/certificates?q=parsed.extensions.certificate_policies.id%3A+1.2.616.1.113527.2.5.1.1+and+validation.nss.paths%3A+85666a562ee0be5ce925c1d8890a6f76a87ec16d4d7d5f29ea7419cf20123b69
• https://search.censys.io/certificates?q=parsed.extensions.certificate_policies.id%3A+2.23.140.1.1+and+validation.nss.paths%3A+3417bb06cc6007da1b961c920b8ab4ce3fad820e4aa30b9acbc4a74ebdcebc65
• https://search.censys.io/certificates/help?q=parsed.extensions.certificate_policies.id%3A+1.2.616.1.113527.2.5.1.1+and+validation.nss.paths%3A+3417bb06cc6007da1b961c920b8ab4ce3fad820e4aa30b9acbc4a74ebdcebc65

SSL.com also performed a full query in the certificate database and did not locate any end-entity TLS Certificates that contain either the 1.2.616.1.113527.2.5.1.1 or the 2.23.140.1.1 OID in the certificatePolicies extension, being issued by an issuing CA that chains to its non-EV Roots.
As a conclusion, even though non-EV hierarchies are technically capable of issuing EV certificates, contractual, organizational and technical measures have been in place since the creation of these hierarchies to ensure no EV certificate is issued by them.

As a remediation measure, SSL.com intends to add the non-EV hierarchies to the EV SSL audit scope, for the audit period July 1, 2022 – June 30, 2023 (which is already in progress) and going forward. In practice, the external audit will provide independent reassurance that no EV TLS Certificate has been issued from these non-EV TLS hierarchies during the audit period.

As these cross-certificates expire in September 2023, and based on the evidence demonstrating that the existing controls have been effective since 2018, we consider this proposed remediation addresses the issue in a reasonable and proportional way. CERTUM will ensure that the proper policy OIDs will be included in the certificatePolicies extension of any renewed cross-certificates to further technically-constrain the EV-enabling policy OIDs.

Would anyone like to provide feedback or ask for further clarification from Certum or SSL.COM? 
Additionally, we would like to discuss whether it is necessary to revoke this cross-certificate.

Flags: needinfo?(aleksandra.kurosz)

The certificates in question (linked below) were issued in September 2018. The BRs in effect at that time were Version 1.6.0 (effective date June 22, 2018).

Version 1.6.0 of the BRs, Section 1.6.1, defines "Affiliate" as "A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity". It is my understanding that, per this definition, SSL.com is not an Affiliate of Asseco DS / Certum. (This definition remains the same today.)

Version 1.6.0 of the BRs, Section 7.1.6.3, also states that "A Certificate issued to a Subordinate CA that is not an Affiliate of the Issuing CA... MUST NOT contain the anyPolicy identifier (2.5.29.32.0)."

(Both of the above statements remain true in the current Version 1.8.6 of the BRs as well.)

https://crt.sh/?sha256=ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B is a Subordinate CA Certificate which is not issued to an Affiliate of the Issuing CA which does contain the anyPolicy identifier.

https://crt.sh/?sha256=B97176F21B6ED64609267B2D1A2A9FAF0C4DEBD44644DC85EB6AE986FC867D56 is the same.

Therefore these certificates were "not issued in accordance with... this document" (BRs Section 4.9.1.2, Paragraph 5) and SHALL be revoked within 7 days.

Unless I'm missing something?

Thanks, Aaron. You are correct.

Please provide a plan for replacing and revoking the certificates, and also file a new incident report / Bugzilla bug for the delayed revocation. Thanks. Ben

Flags: needinfo?(aleksandra.kurosz)

We are still investigating this issue. We are checking the applicable requirements and policies. We will respond to this bug by end of the week at the latest.

This text is in response to https://bugzilla.mozilla.org/show_bug.cgi?id=1815355#c8 after internal discussions and approval from Certum.

Historically, Cross Certificates have been treated differently than the typical Subordinate CA Certificates that issue Subscriber Certificates. The Certificate Profiles defined for Subordinate CA Certificates did not always apply to Cross-Certificates, especially for the cases of linking two Root CA Certificates. The Baseline Requirements for TLS Certificates version 1.6.0 specifically calls out “Cross Certificates” only in section “7.1.3 Algorithm Object Identifiers,” treating them as Root CA Certificates. Future versions tried to clarify more areas where “Cross Certificates” should be considered, in addition to or in contrast with the typical “Subordinate CA Certificates”.

We also reviewed open and closed incidents (bugs in Bugzilla) related to the tags [ca-misissuance], [audit-failure]. We could not identify any identical incident related to cross-certificates including or missing the certificatePolicies extension. There was one similar bug which involved policy OID inconsistencies (https://bugzilla.mozilla.org/show_bug.cgi?id=1650018) and which resulted in the conclusion that further clarifications were needed in the Baseline Requirements without the need to revoke any matching cross-certificates.

After a quick search on crt.sh, we discovered several cross certificates or CA Certificates issued to externally-operated CAs that contained the “anyPolicy” OID in the certificatePolicies extension. Here is an indicative list:

• https://crt.sh/?id=1027088119
• https://crt.sh/?id=5916597703
• https://crt.sh/?id=1027087968
• https://crt.sh/?id=2841732943
• https://crt.sh/?id=13560235
• https://crt.sh/?id=607203242 (According to CCADB this SubCA is operated by Digicert)

This is an indication that back in 2018 when the cross-certificates were issued, it was an acceptable industry practice to include a certificatePolicies extension with the “anyPolicy” OID because the issuer could not know beforehand what other new policy OIDs would be created by the subject CA in the upcoming years. As an example, consider the introduction of the IV TLS policy OID or the OIDs introduced by the S/MIME Baseline Requirements for a cross-certificate that spans across multiple trust ecosystems (TLS and S/MIME). These OIDs did not exist in the past so it did not make sense to be included in a cross-certificate that allows trust to flow from one multi-purpose Root (CERTUM) to another (SSL.com). Using multi-purpose hierarchies is no longer considered a “good practice” which is why CAs are migrating to single-purpose ecosystems, to minimize policy conflicts between different ecosystems. However, this was still considered okay when these cross-certificates were issued. This ambiguity has been addressed by the CA/B Forum Server Certificate Working Group in the “Certificate Profiles Update ballot (SC-062)”. However this will affect cross certificates issued after the effective date of that ballot and should not retroactively be applied to the cross-certificates in question.

Based on these facts, we do not consider these certificates mis-issued. These Cross Certificates were audited and disclosed to the community and Browsers for more than four years and have been used by millions of Relying Parties without causing any interoperability or compliance issues. Revoking or even removing trust from these Cross Certificates (via other methods like OneCRL) will cause more harm than good because they are effectively installed in the certificate paths of hundreds of thousands of internet websites, especially given the fact that these cross-certificates expire in a few months (September 2023).

We believe that remediation measures described in https://bugzilla.mozilla.org/show_bug.cgi?id=1815355#c6 are adequate and reasonable, considering the currently identified risks and the scope of the issue raised here.

The examples given above are for CA certificates that are now revoked, or were EKU-constrained to clientAuth or emailProtection, or in the case of the Amazon subCA, "issued to a Subordinate CA that is an affiliate of the Issuing CA".

In response to https://bugzilla.mozilla.org/show_bug.cgi?id=1815355#c13, we would like to share the following: 

  • https://crt.sh/?id=1027088119, https://crt.sh/?id=5916597703 and https://crt.sh/?id=1027087968 are intermediate CA certificates without the TLS server authentication EKU but which chain to a Root CA trusted for TLS. The BRs don’t state explicitly that they are exempted from the anyPolicy prohibition. In fact, in the recently voted Server Certificate Working Group ballot SC-62 section 7.1.2.3.2 “Technically Constrained Non-TLS Subordinate CA Certificate Policies”, the clarification is that, even for non-TLS subCAs, the anyPolicy OID is only allowed for the issuing (Root) CA and affiliates. 
     
  • https://crt.sh/?id=2841732943 is a cross certificate for an intermediate CA which was revoked on 2020-07-30. Our investigation revealed that this revocation took place a few days after the discussion of https://bugzilla.mozilla.org/show_bug.cgi?id=1650018 (2020-07-02), when the anyPolicy ambiguity in the BRs was confirmed. The lack of public incident or request from the community for the CA to file a public incident is an indication that this was not considered a mis-issuance at that time. 
     
  • https://crt.sh/?id=13560235 was revoked for a different reason based on https://bugzilla.mozilla.org/show_bug.cgi?id=1397954, not because of the anyPolicy OID. This is another indication that the use of anyPolicy OID was considered an acceptable practice at that time. 
     
  • CCADB and audit reports (e.g. https://bug1807304.bmoattachments.org/attachment.cgi?id=9309729) indicate that https://crt.sh/?id=607203242 is operated by DigiCert while the Root belongs to Amazon. We consider this case to be relevant as well, since to the best of our knowledge DigiCert and Amazon are not affiliated. 
     
    Please note that we did not perform an exhaustive search for these cases in CCADB, crt.sh, CENSYS etc. These are just a few examples discovered after a cursory search. 
     
    Once again, we would like to highlight that the cross-certificates in question were issued in September 2018, before those ambiguities were revealed and confirmed by the community. Now that these have been addressed in the TLS Baseline Requirements, any new cross-certificate issued to a non-affiliate will contain specific policy OIDs and not the anyPolicy OID.

(In reply to Chris Kemmerer from comment #14)

Of course, we will revisit the concerns that you are identifying about other CA's cross-signings, but in this Bug I would like to focus on the problem that I identified and how you are going to resolve the failure.

Once again, we would like to highlight that "the cross-certificates in question were issued in September 2018", before those ambiguities were revealed and confirmed by the community. Now that these have been addressed in the TLS Baseline Requirements, any new cross-certificate issued to a non-affiliate will contain specific policy OIDs and not the anyPolicy OID.

The problem is that "the cross-certificates in question were issued in September 2018" were capable if issuing EV TLS certificates, but were not being audited according to the EV audit criteria. I don't believe there has ever been any ambiguity about Mozilla's requirement that certificates that are capable if issuing EV TLS certificates must be audited annually according to the EV audit criteria.

I do agree that Mozilla has allowed time for CAs to obtain the necessary audits when requirements have changed, for example https://wiki.mozilla.org/CA/Communications#May_2014. However, I think it is completely unacceptable that "the cross-certificates in question were issued in September 2018" have not been getting EV audited since 2018.

The responsibility is on the CA to understand the types of certificates the issuing certs in their CA hierarchy can issue, and provide the applicable annual audit statements.

Therefore, please focus on what went wrong to allow the problem reported in this bug to go unnoticed by anyone in your CA operations for so many years (e.g. why did the problem go unnoticed until I filed this bug), what the correct thing is to do about it, when you will do that, and how you will prevent repeating this mistake in the future.

Hello! Please note that I, Thomas Zermeno, will be taking over communications duties representing SSL.com from Chris Kemmerer, who is leaving the company. We appreciate all his efforts and contributions, and I look forward to continuing my participation on behalf of SSL.com.

(In reply to Kathleen Wilson from comment #15)

Please also note that the following response has been reviewed and approved by Certum.

Regarding the original issue of this bug (audit failure), we would like to explain the position of Certum and SSL.com as to why the EV TLS audit scope was not included in audit reports up to now. We believe the arguments are honest and reasonable considering the policies and practices of the webPKI ecosystem since 2018. We still treat this as a failure on our part for not detecting the CCADB conflict sooner.

The problem is that "the cross-certificates in question were issued in September 2018" were capable if issuing EV TLS certificates, but were not being audited according to the EV audit criteria. I don't believe there has ever been any ambiguity about Mozilla's requirement that certificates that are capable if issuing EV TLS certificates must be audited annually according to the EV audit criteria.

As Certum explained in Comment 3 (sub-item 6), Comment 5 (sub-item 5), and SSL.com explained in Comment 6, SSL.com did not allow issuance of EV TLS Certificates chaining to its non-EV Root hierarchy. There were a series of technical measures in place to prevent that from happening. This can also be verified independently with the queries posted in Comment 6 which show that no EV TLS Certificate has ever been issued from SSL.com’s non-EV hierarchy. These technical controls preventing EV issuance, and the policies agreed between Certum and SSL.com, were reasonably considered enough to exclude the EV audit criteria from the audit scope, which was also not required by MRSP at the time (see below).

I do agree that Mozilla has allowed time for CAs to obtain the necessary audits when requirements have changed, for example https://wiki.mozilla.org/CA/Communications#May_2014. However, I think it is completely unacceptable that "the cross-certificates in question were issued in September 2018" have not been getting EV audited since 2018.

The expectations in MRSP 2.7 stated that the CA needed to be audited in scope of the EV only if it was issuing EV Certificates, not if it was capable of issuing such certificates. That point was later clarified in MRSP 2.8 when “if issuing EV certificates” was changed to “if capable of issuing EV certificates”.

The responsibility is on the CA to understand the types of certificates the issuing certs in their CA hierarchy can issue, and provide the applicable annual audit statements.

Therefore, please focus on what went wrong to allow the problem reported in this bug to go unnoticed by anyone in your CA operations for so many years (e.g. why did the problem go unnoticed until I filed this bug), what the correct thing is to do about it, when you will do that, and how you will prevent repeating this mistake in the future.

SSL.com has a dedicated EV hierarchy as explained in Comment 6, using a dedicated cross-certificate issued by Certum (https://crt.sh/?id=759010264). This hierarchy has always been audited against the EV criteria as it was (and still is) actively issuing EV Certificates.

SSL.com also has a non-EV hierarchy using a different dedicated cross-certificate issued by Certum (https://crt.sh/?id=759010256). Based on the applicable policies at that time, SSL.com had no reason to include an EV audit scope for the non-EV hierarchy, despite being chained to Certum’s EV-enabled Root. That is the primary reason why SSL.com did not consider adding these non-EV CAs in the EV audit scope. Both SSL.com and Certum have demonstrated competence in being audited against the EV criteria, so adding those non-EV issuing CAs to the EV audit scope would be trivial and would only re-confirm that no EV Certificate had been issued from that hierarchy.

SSL.com has already contacted its Qualified Auditor, BDO, and agreed to add the EV audit scope in the current audit period (July 1, 2022 – June 30, 2023) for the non-EV TLS CAs which will remediate the audit failure since MRSP policy 2.8 became effective and going forward. This plan was emailed to Ben Wilson (copied also to BDO and Certum) on March 13, 2023.

In addition to this, SSL.com and Certum plan to add monitoring controls to check https://crt.sh/mozilla-disclosures#disclosureincomplete as a secondary measure to flag similar future audit reporting issues.

Once again, we would like to express our disappointment at not detecting this issue sooner. Going forward, Certum and SSL.com will be taking into consideration all possible chain-building paths. If any of those paths can assert (per RFC 5280) an EV-enabling policy OID, chaining to an EV-enabled Root, they will be added to the EV audit scope regardless of EV Certificates actively being issued or not.

(In reply to Thomas Zermeno from comment #16)

The expectations in MRSP 2.7 stated that the CA needed to be audited in scope of the EV only if it was issuing EV Certificates, not if it was capable of issuing such certificates. That point was later clarified in MRSP 2.8 when “if issuing EV certificates” was changed to “if capable of issuing EV certificates”.

I see.

The text in MRSP was changed to "capable of issuing EV certificates" in version 2.7.1 which became effective May 1, 2021.

So up until May 1, 2021, the "series of technical measures in place to prevent" EV issuance would have been in line with MRSP of "if issuing EV certificates".

That means that technically the problem here only applies to the audit statements that were issued for audit statements provided after May 1, 2021.

From Comment #6:

SSL.com has fulfilled this obligation which can be demonstrated by the following:
• The issuance of an EV TLS Certificate from the non-EV hierarchies would be detected and considered a mis-issuance, flagged in annual audit reports.
• Searching CT logs proves that no EV-enabled policy OID has been included in end-entity certificates issued from the non-EV hierarchies.
• SSL.com is CT logging all issued end-entity certificates.

OK. This technically shows no EV issuance in this CA hierarchy.

SSL.com has already contacted its Qualified Auditor, BDO, and agreed to add the EV audit scope in the current audit period (July 1, 2022 – June 30, 2023) for the non-EV TLS CAs

OK. This resolves the issue from July 1, 2022 onward.

In addition to this, SSL.com and Certum plan to add monitoring controls to check https://crt.sh/mozilla-disclosures#disclosureincomplete as a secondary measure to flag similar future audit reporting issues.

Good idea.

Going forward, Certum and SSL.com will be taking into consideration all possible chain-building paths. If any of those paths can assert (per RFC 5280) an EV-enabling policy OID, chaining to an EV-enabled Root, they will be added to the EV audit scope regardless of EV Certificates actively being issued or not.

Good.

Ben and Thomas, I am OK with resolving this bug as fixed as long as all of the following points are true. Please confirm.

  • The auditor will add the EV audit scope in the current and future audit periods for the CA certificates in this hierarchy until these cross-certificates expire or are revoked.
  • The cross-signing was done in 2018, but MRSP was not clarified about EV-capable until May 1, 2021. So it was technically one audit statement that was non-compliant due to an unfortunate oversight that has been resolved.
  • The CA is CT logging all issued TLS certificates, and no EV TLS certificates have been issued in this cross-signing hierarchy.
  • These cross-certificates expire soon (September 2023), and Certum and SSL.com will ensure that the proper policy OIDs will be included in the certificatePolicies extension of any new cross-certificates that they are involved in.
  • A representative of either SSL.com or Certum will post in MDSP advice for other CAs about cross-signing considerations.

Thanks,
Kathleen

Thank you, Kathleen,

In regards to the bullet points:

  • The auditor will add the EV audit scope in the current and future audit periods for the CA certificates in this hierarchy until these cross-certificates expire or are revoked.

    • SSL.com confirms and has already made the necessary arrangements with the Qualified Auditor.

  • The cross-signing was done in 2018, but MRSP was not clarified about EV-capable until May 1, 2021. So it was technically one audit statement that was non-compliant due to an unfortunate oversight that has been resolved.

  • The CA is CT logging all issued TLS certificates, and no EV TLS certificates have been issued in this cross-signing hierarchy.

    • SSL.com confirms that all issued TLS Certificates are CT logged (EV and non-EV).
    • SSL.com also confirms that no EV TLS certificates have been issued in this cross-signing hierarchy.

  • These cross-certificates expire soon (September 2023), and Certum and SSL.com will ensure that the proper policy OIDs will be included in the certificatePolicies extension of any new cross-certificates that they are involved in.

    • We confirm.

  • A representative of either SSL.com or Certum will post in MDSP advice for other CAs about cross-signing considerations.

    • We will prepare and send some guidance to MDSP regarding this incident and our experience gained during the course of this bug.

This message serves as an update to the community that we are preparing a response to Bug #1815355, which we will post to the MDSP by the end of May. This response will include a summary of lessons learned throughout the course of this Bug as well as other advice for CAs with cross-signing considerations.

We have posted our Lessons Learned statement to the m.d.s.p. group. This concludes the pending actions of this bug.

Please let us know if there are any further questions or concerns about this bug.

Regards,

Tom
SSL.com

Flags: needinfo?(kwilson)

(In reply to Thomas Zermeno from comment #20)

We have posted our Lessons Learned statement to the m.d.s.p. group. This concludes the pending actions of this bug.

Thank you for sharing the write-up in MDSP, along with your recommendations.

Ben, I am OK with closing this bug.

Flags: needinfo?(kwilson) → needinfo?(bwilson)

I intend to close this issue next Wed., 7-June-2023.

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Flags: needinfo?(aleksandra.kurosz)
You need to log in before you can comment on or make changes to this bug.