1799533 - Add SSL.com 2022 TLS Root CA Certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task, P2)

Description

[SSL.com]

Attachment: SSL.com CA Compliance Self Assessment 2022-11-07.xlsx

Steps to reproduce:

SSL.com requests the addition of two Root CA Certificates to NSS and the Mozilla root store. These roots are intended to be used for TLS Server authentication, and we request enabling of the Web Sites trust bit and EV treatment for these roots.

We intend to migrate all TLS issuance to subCAs chaining to these roots.

We have filed a CCADB case (00001049) for inclusion of these two root certificates, and expect these new roots to be included our current audit cycle. Our self-assessment is attached.

Comment 1

[SSL.com]

Attachment: ev-ecc-test.png

Comment 2

[SSL.com]

Attachment: ev-rsa-test.png

Comment 3

[SSL.com]

Key management lifecycle reports are now uploaded to our audit documentation bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1390314, h/t Ben Wilson for his assistance with this). Direct links to these reports:

SSL COM Enterprise Key Gen Indp Acct Report and Mgmt Assertion Oct 2018: https://bugzilla.mozilla.org/attachment.cgi?id=9306498
SSL.com Enterprise Key Lifecycle Mgmt Indp Acct Report and Mgmt Assertion June 2020: https://bugzilla.mozilla.org/attachment.cgi?id=9306497
SSL.com WTCA Key Lifecycle Mgmt Indp Acct Opinion and Mgmt Assertion June 2021: https://bugzilla.mozilla.org/attachment.cgi?id=9306499
SSL.com WTCA Key Lifecycle Mgmt Indp Acct Opinion and Mgmt Assertion June 2022: https://bugzilla.mozilla.org/attachment.cgi?id=9306501

The algorithm that was used to produce the fingerprints in each report is SHA-256 (Public key bitstring). Essentially, it is the same as the first one specified in RFC 5280 section 4.2.1.2, but with SHA-1 replaced by SHA-256.

Comment 4

[Ben Wilson]

I'm looking for the following SPKIs:
2BCF553A66F570900DDD32BA6DFE1ECC06C9182D662DC1B60E1F7B767C2BDD54
1BF00D5C8F13C094DD17E00504CF0888850F12FD067FA1F92C0FDBF60B86E321
4C3432C984C66AE2A754743983CA8969E2F10F4086384DC38B8060532CB0BEA7
3A0EC54C1832A281DC3062267FD937429008E1C841B37B4A79AB1BDD4CBA57FF

Comment 5

[SSL.com]

(In reply to Ben Wilson from comment #4)

I'm looking for the following SPKIs:
2BCF553A66F570900DDD32BA6DFE1ECC06C9182D662DC1B60E1F7B767C2BDD54
1BF00D5C8F13C094DD17E00504CF0888850F12FD067FA1F92C0FDBF60B86E321
4C3432C984C66AE2A754743983CA8969E2F10F4086384DC38B8060532CB0BEA7
3A0EC54C1832A281DC3062267FD937429008E1C841B37B4A79AB1BDD4CBA57FF

These SHA-256 SubjectPublicKeyInfo hashes correspond to the following SHA-256 subjectPublicKey hashes in the reports:

2BCF553A66F570900DDD32BA6DFE1ECC06C9182D662DC1B60E1F7B767C2BDD54 -> 45F3DDEB7B98CE6D7E15ED5487DAAD06E9FF925E0B8249E01DE7B7580B3A0B83

1BF00D5C8F13C094DD17E00504CF0888850F12FD067FA1F92C0FDBF60B86E321 -> 0DF292BB997731DAB9797EFAA7A69B1FEC16D2DCF44A72F35E062EC57B52EDA0

4C3432C984C66AE2A754743983CA8969E2F10F4086384DC38B8060532CB0BEA7 -> E1F02DA2F485C9BCD814E006542D60BBCD561209BA40F57C10E6469B4A5BD8F7

3A0EC54C1832A281DC3062267FD937429008E1C841B37B4A79AB1BDD4CBA57FF -> 9D84885AF8E25AECC7512BC8E5792374DC07A05D90E2EB8D71C9457E13FD0ED5

The following sets of commands may be used to verify the results:

openssl x509 -in SSLcom-TLS-Root-2022-RSA.pem -pubkey -noout | openssl pkey -pubin -outform der | sha256sum
openssl x509 -in SSLcom-TLS-Root-2022-RSA.pem -pubkey -noout | openssl asn1parse -strparse 19 -noout -out /dev/stdout | sha256sum

openssl x509 -in SSLcom-TLS-Root-2022-ECC.pem -pubkey -noout | openssl pkey -pubin -outform der | sha256sum
openssl x509 -in SSLcom-TLS-Root-2022-ECC.pem -pubkey -noout | openssl asn1parse -strparse 20 -noout -out /dev/stdout | sha256sum

openssl x509 -in SSLcom-Client-Root-2022-ECC.pem -pubkey -noout | openssl pkey -pubin -outform der | sha256sum
openssl x509 -in SSLcom-Client-Root-2022-ECC.pem -pubkey -noout | openssl asn1parse -strparse 20 -noout -out /dev/stdout | sha256sum

openssl x509 -in SSLcom-Client-Root-2022-RSA.pem -pubkey -noout | openssl pkey -pubin -outform der | sha256sum
openssl x509 -in SSLcom-Client-Root-2022-RSA.pem -pubkey -noout | openssl asn1parse -strparse 19 -noout -out /dev/stdout | sha256sum

Comment 6

[Ben Wilson]

Attachment: SSL.com CA Compliance Self Assessment - Mozilla comments.xlsx

Here are my comments based on a review of the CP/CPS v. 1.16 and the self-assessment. SSL.com should review and respond to my comments in this bug.

Comment 7

[Ben Wilson]

By the way, public discussion began 3/21/2023 and is scheduled to end 5/2/2023 - https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/bBl1fCN5AAAJ

Comment 8

[SSL.com]

Ben,
Thank you for taking the time to review our CP/CPS. We are already on it and we plan to post a progress update to Bug #1799533 by the end of next week.

Comment 9

[SSL.com]

Attachment: SSL.com CA Compliance Self Assessment - remediation status 2023-04-21.xlsx

Comment 10

[SSL.com]

Ben,

We would like to update you as to our progress on the comments that you presented to us earlier. We have examined our CP/CPS and found that the specified sections could, indeed, be better phrased to match the expectations of the industry and have begun updating our practices document to better reflect the needs of the community. We have addressed all comments related to the BRs and Mozilla Root Store Policy. Please see the attached .xlsx file (https://bugzilla.mozilla.org/attachment.cgi?id=9329748) for specific changes to be made effective in the next version of our CP/CPS (v1.17).

We are currently working on the evaluation and updates to the EV Requirements based on your comments and consideration of CPS documents from other CAs. Our approach will be to describe the extended validation process, referring to more specific sections of EVGL where appropriate. We would appreciate your input on this as we draft the text of the updated language.

We will provide a report on our progress next week.

Comment 11

[Dustin Ward]

Attachment: SSL.com CA Compliance Self Assessment - Mozilla comments - part 2 (2023-04-26).xlsx

Ben,

This is an update to report on our progress since our previous post.

All EVGL-related comments have now been addressed; this completes our CP/CPS updates for this bug. Please see the attached .xlsx file which complements our previous report on changes to be made effective in the next version of our CP/CPS (v1.17). Your comments are more than welcomed.

Per our standard processes, CP/CPS updates shall pass through internal review and PMA approval before v1.17 is issued and becomes effective. All actions are scheduled to be completed no later than May 15, 2023.

Comment 12

[Ben Wilson]

I am recommending that we approve SSL.com's request - see https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/VqnAop6IPcc/m/HBSReRTPAAAJ

Comment 13

[SSL.com]

We would like to update the community with regards to the publication of the SSL.com CP/CPS v1.17. The updates were approved by our PMA on Friday, May 12 and we are now working on resolving some formatting issues. The document will be available in our repository and uploaded to the CCADB within the required 7 day period ending Friday, May 19.

Comment 14

[Kathleen Wilson]

Thomas, Please fix the test websites...

See https://crt.sh/test-websites
which shows the "Wrong chain" error for both test websites.

And https://tls-observatory.services.mozilla.com/static/ev-checker.html fails...

TLS Server: https://test-root-2022-rsa.ssl.com
EV Policy OID: 2.23.140.1.1
PEM for SSL.com TLS RSA Root CA 2022
exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_UNKNOWN_ISSUER Peer's Certificate issuer is not recognized.

TLS Server: https://test-root-2022-ecc.ssl.com
EV Policy OID: 2.23.140.1.1
PEM for SSL.com TLS ECC Root CA 2022
exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_UNKNOWN_ISSUER Peer's Certificate issuer is not recognized.

The problem might simply be that the web server is not serving up the intermediate certificates when it serves up the TLS cert.

Comment 15

[SSL.com]

Thank you Kathleen; the full chains have been properly installed and all the readiness checks show success. Please verify and let us know if you continue to have issues.

Comment 16

[Kathleen Wilson]

Thanks Thomas.

Before continuing with this request, I need to fully understand the relationship between SSL.com and e-Tugra, so I am marking this Bugzilla bug as dependent on Bug #1832570.

Comment 17

[xiaohui.lam]

Kathleen,

By my understanding, SSL.com company's relationship with e-Tugra is only a reseller contract including subordinate CAs customized service,
All e-Tugra customer's signing request, wasn't processed directly by e-Tugra, but have to send to SSL.com's API(they call the SWS API, which full disclosures at https://www.ssl.com/ssl-web-services-sws-api/ ).

Based on the above premise, and a same role with a e-Tugra, we're also a reseller, both of us can't issue all certificates without SSL.com API; so you can understand, all the randome unique value sents to email for domain validation, can't be predicted by e-Tugra. In a other word, e-Tugra has no ability to validate domain name for certs under SSL.com subCAs without domain owner's permission, even their system been hacked.

---

A little information of me. I'm a co founder of Quantum CA Limited, our contract includes reselling certificate of SSL.com and subordinate CAs same customized service as e-Tugra do.

All information can be verified, if you sign up an account on ssl.com and try access to submit certificate signing request.

Comment 18

[Kathleen Wilson]

Adding this back to my own NeedInfo queue, but I will not make a decision until Bug #1832570 has been resolved.

Comment 19

[Kathleen Wilson]

Thomas,

I'm going to put this back into your queue... It may be unfortunate coincidence, but I'm concerned about the cluster (see list below) of recent issues having to do with SSL.com relationships with other CAs and resellers. Please do a very thorough review of all of SSL.com's resellers, re-branded intermediate CAs, and cross-signing relationships with other CAs. And report back here with a public-facing summary of your findings and any resolutions.

1. Bug #1815355 - Asseco Data Systems cross-signed a non-EV SSL.com root, mistakenly making it EV-capable -- lessons learned

2. Bug #1801345 - Breach of e-Tugra systems that were reselling certificates through a branded intermediate certificate operated by SSL.com.

3. Discussion in MDSP - SSL.com discovered that reseller QUANTUM CA LIMITED had dissolved on November 1, 2022, and not notified SSL.com.

I will wait for a report of your results before making a determination about this root inclusion request.

Comment 20

[Leo Grove]

Hello Kathleen,

We understand the concerns you have and will address them in a transparent and actionable manner. It is our hope that our introspective analysis of our resellers, branded intermediates, and cross-signing relationships will provide you with the answers you need to move forward with our root inclusion request.

First, we considered the branded CA partnerships that SSL.com has developed over the years. Of the 16 organizations that we have generated branded CAs for, 12 are confirmed to still be active and 4 are no longer active. Of those 4, 3 notified SSL.com about their planned dissolution and their branded CA certificates were properly revoked prior to the root inclusion request. The only organization that did not notify SSL.com was Quantum CA Limited. As explained in the MDSP thread, we are currently in the process of revoking those certificates.

SSL.com has only entered into one cross-signing agreement with another CA, namely Asseco Data Systems (CERTUM), which signed two SSL.com Root CAs in 2018 with their Root to provide the necessary ubiquity, allowing SSL.com to conduct business in the publicly-trusted ecosystem. The cross-certificates signed by CERTUM will expire in September of this year. There are no current plans to renew these cross-certificates or enter into another cross-certificate agreement. SSL.com has not cross-signed any third-party company.

Finally, we have our volume discount/reseller customers who do not have branded CAs. This makes up a sizeable portion of our client base; we are reaching out to these customers via email notifications to remind them of their commitment to security and offering them advice and assistance on how to improve their customer portals, if they have one (see also our post in bug #1832570 regarding the public security guidance for subscribers/resellers and improvements in current agreements). This is part of a larger initiative to educate our customers about changes in the industry and to keep them aware of any new threats. Our goal is to ensure that all data and PII is kept safe and that access to such data is limited to only those that need to use it.

We hope this provides adequate clarity into the relationships SSL.com has with other CAs and resellers, and how we can improve on our current processes. We are available to answer any questions and to address any other concerns in relation to our root inclusion request. Thank you for your time on these matters.

Regards,

Leo Grove

Comment 21

[Kathleen Wilson]

Thanks, Leo. Putting this back into my queue.

Comment 22

[Kathleen Wilson]

As per Comment #12, and on behalf of Mozilla I approve this request from SSL.com to include the following root certificates:

** SSL.com TLS RSA Root CA 2022 (Websites); EV
** SSL.com TLS ECC Root CA 2022 (Websites); EV

I will file the NSS and PSM bugs for the approved changes.

Comment 23

[Kathleen Wilson]

I have filed bug #1839992 against NSS and bug #1839996 against PSM for the actual changes.