1532426 - Add SSLCOM to your trusted root CA cert list

Status: RESOLVED WONTFIX

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

Description

[Dori Ephrat]

Attachment: SSLCOM WebTrust CA Audit Report.pdf

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36

Steps to reproduce:

built a CA compliant with WebTrust rules. Attached you"ll find confirmation form a WebTrust Approved auditor

Comment 1

[Ryan Sleevi]

Please see https://wiki.mozilla.org/CA/Application_Instructions for how to apply - notably, providing all of the information necessary for the CA Information Checklist.

Note that, as per https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#312-required-audits , the current audit provided is necessary, but not necessarily sufficient, for inclusion.

Comment 2

[Dori Ephrat]

Attachment: SSLCOM WebTrust SSL Audit Report.pdf

attached is the missing SSL audit report

Comment 3

[Yosi Rosner]

As the CA manager and owner I assign Mr. Dori Ephart as co POC

Comment 4

[Yosi Rosner]

As the CA manager and owner I assign Mr. Dori Ephrat as co POC

Comment 5

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000410

The CA representative may directly enter and update the information when logged into the CCADB here:
https://ccadb.force.com/5001J00000hxG4p

The CA needs to follow steps 5 through 8 here:
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Then add a comment to this bug when all of the required information has been provided.

Comment 7

[Kathleen Wilson]

I receive email from Dori on April 19 that the Root Inclusion Case has been updated. I will review the information now.

Comment 8

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000410

Search for the word NEED to see where further information must be provided by the CA.

In particular:

1. Resolve website and TLS cert problems
   -- https://www.sslcomgroup.com configured with an invalid TLS cert for this domain.
   -- There is no document repository web page listing what is available. The current link is just to the CPS.
   -- Browsing to https://www.sslcomgroup.com results in XML errors.
   -- CPS needs to be updated to provide statement binding it to the root certificates "SSLCom Root G1" and "Almost Free SSL RootCA G1", and all of their subordinate CA certificates.

2. Complete BR Self Assessment (https://wiki.mozilla.org/CA/BR_Self-Assessment) and attach it to this bug.

3. Full compliance with the CA/Browser Forum's Baseline Requirements includes this requirement
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
   Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.

4. Need period of time audit statements covering both roots. Please have your auditor include both roots in a single WebTrust CA audit statement and a single WebTrust BR audit statement.
   Here are the audits that have been provided so far (they are point-in-time).
   WebTrust CA Readiness audit for "SSLCom Root G1":
   https://bug1532426.bmoattachments.org/attachment.cgi?id=9048308
   WebTrust BR Readiness audit for "SSLCom Root G1":
   https://bug1532426.bmoattachments.org/attachment.cgi?id=9048315
   WebTrust CA Readiness audit for "Almost Free SSL RootCA G1"
   https://bug1535673.bmoattachments.org/attachment.cgi?id=9051337
   WebTrust BR Readiness audit for "Almost Free SSL RootCA G1"
   https://bug1535673.bmoattachments.org/attachment.cgi?id=9051338

5. Check if section 3.2.5 is correct. It currently says:
   "The CA uses a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request. The method described in section 3.2.4 above shall be considered a reliable method herein."
   and section 3.2.4 says:
   "The SSLCOM CA shall not be responsible for any non-verified individual or organizational information submitted for the purpose of inclusion in the certificate."
   So if it is correct, then now validation of authority is performed?

6. Update the CPS to provide a section that describes the CA hierarchy, what types of certificates may be directly signed by the root certs, and what types of certificates may be signed by the intermediate certs.

7. Explain why these root certs needs to be included in the root store, rather than being signed by another CA’s root certificate that is already included.
   Explain the unique function of each root.
   Root Certificate Download URL
   Provide a public URL for each of the root certificates, where they can be directly downloaded.

8. For both root certs, provide URLs to 3 test websites (valid, expired, revoked) whose TLS/SSL cert chains up to this root, as required by section 2.2 of the CAB Forum's Baseline Requirements.

9. Test and provide testing results for both root certs
   -- Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
   -- Provide evidence that you have tested and verified that no certificates issued in this CA hierarchy violate any of the CA/Browser Forum Baseline Requirements (BRs).
   BR Lint Test: https://github.com/awslabs/certlint
   X.509 Lint Test: https://github.com/kroeckx/x509lint
   https://crt.sh/?a=1
   es.

10. Add records for the existing intermediate certs to the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

11. If Mozilla accepts and includes your root certificate(s), then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor and must be documented in your CPS. Your CPS must make it clear that all of the rules therein also apply to all subCAs, and if such subCAs will be technically constrained and how.

Comment 9

[Dori Ephrat]

We have completed the BR self assessment and have a new repository

Comment 10

[Dori Ephrat]

Attachment: SSLCOMGROUP's BR Self Assessment.xlsx

AllmostfreeSSL BR self assessment

Comment 11

[Dori Ephrat]

Attachment: SSLCom CPS v1.2.pdf

latest CPS

Comment 12

[Kathleen Wilson]

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000410

In particular:

1. "Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue."
   For example, this might be sslcomgroup.com, almostfreessl.com
   But should be the list that your CA's code actually checks, and should match the info in the CAA section of your CPS

2. Please provide period of time audit statements covering both roots, and have your auditor include both roots in a single WebTrust CA audit statement and a single WebTrust BR audit statement. Make sure the audit statements meet Mozilla's root store policy requirements
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

3. Explain why each root cert needs to be included in the root store, rather than being signed by another CA’s root certificate that is already included. Explain the unique function of each root.

4. The test websites for the "SSLCom Root G1" root must actually chain up to the "SSLCom Root G1" root.
   When the test websites are available for this root cert, then:
   Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
   Lint test: enter the certs in the cert chain for the test websites into "Certificate Linter" at https://crt.sh/?a=1 and provide results. All errors must be resolved.

5. Resolve all errors listed here: https://certificate.revocationcheck.com/testvalid.almostfreessl.com

6. Resolve the problems that are causing the "Test Websites Validation" to fail for all 3 of the test websites for the "Almost Free SSL RootCA G1" root.

7. The TLS cert for https://testvalid.almostfreessl.com not BR compliant. Therefore, before continuing with this request, the CA must implement pre-issuance lint testing, and provide assurance it is in place and working.
   I entered the certs in the chain for https://testvalid.almostfreessl.com/ into "Certificate Linter" at https://crt.sh/?a=1
   TLS cert has errors:
   x509lint ERROR No Subject alternative name extension
   zlint ERROR Subscriber certificates MUST contain the Subject Alternate Name extension
   zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension

Comment 13

[Dori Ephrat]

following your request "Explain why each root cert needs to be included in the root store, rather than being signed by another CA’s root certificate that is already included. Explain the unique function of each root.", we decided that at this time that having a root store for allmostfreessl is enough. In the future we might re-initiate the request for sslcomgroup for commercial reasons

Comment 14

[Dori Ephrat]

can we proceed from here or you need to readjust the case?

Comment 15

[Kathleen Wilson]

(In reply to Dori Ephrat from comment #14)

can we proceed from here or you need to readjust the case?

I have a large backlog, so it will take me a while to get back to this request. In the meantime, please make sure that you resolve all of the items listed in Comment #12 in regards to the root cert that you are continuing to request inclusion for.

Comment 16

[Dori Ephrat]

Attachment: SSLCom CPS v1.3.pdf

Comment 17

[Dori Ephrat]

Attachment: SSLCOM WebTrust CA.pdf

Comment 18

[Dori Ephrat]

Attachment: SSLCOM WebTrust SSL.pdf

Comment 19

[Dori Ephrat]

(In reply to Kathleen Wilson from comment #15)

(In reply to Dori Ephrat from comment #14)

can we proceed from here or you need to readjust the case?

I have a large backlog, so it will take me a while to get back to this request. In the meantime, please make sure that you resolve all of the items listed in Comment #12 in regards to the root cert that you are continuing to request inclusion for.

Could you please estimate when you'll get back to this request?
Dori

Comment 20

[Dori Ephrat]

Please notice that we go forward with allmostfreessl so our sslcomgroup "Test Websites Validation Results" fail (could not remove them) but the allmostfree ones pass

Comment 21

[Kathleen Wilson]

I have re-reviewed this request, and updated it to withdraw the "SSLCom Root G1" root.

The link below shows the CA information that has been verified.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000410

1. When do you expect to have the first period of time audit for the "Almost Free SSL RootCA G1" root and hierarchy?

2. Please resolve all errors listed here:
   https://certificate.revocationcheck.com/testvalid.tagim2.polimil.com
   e.g.
   ERROR: Response expired 278h44m7s ago
   ERROR: The Cache-Control max-age header outlives NextUpdate with 278h44m7s

Comment 22

[Dori Ephrat]

addressing both issues in comment 21

1. our first period of time audit has started and we expect to end end it by the end of October (delays may occur since we have a few holidays coming)

2. errors resolved

Comment 23

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000410

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Dori, Please add a comment to this bug when the period of time audit is available.

Comment 24

[Dori Ephrat]

Attachment: new WebTrust audits

Comment 25

[Dori Ephrat]

Attachment: SSLCOM WebTrust SSL Audit Report 2020.pdf

Comment 26

[Dori Ephrat]

Attachment: SSLCOM WebTrust Ca Audit Report 2020.pdf

Comment 27

[Kathleen Wilson]

Dori, Please have your auditor issue audit statements that follow the formatting requirements listed here:
https://www.ccadb.org/policy#51-audit-statement-content
In particular:
"Format Specifications for SHA-256 Fingerprints:

• MUST: No colons, no spaces, and no line feeds"

Comment 28

[Dori Ephrat]

Attachment: SSLCOM WebTrust CA Audit Report 2020.pdf

Comment 29

[Dori Ephrat]

Attachment: SSLCOM WebTrust SSL Audit Report 2020.pdf

Comment 30

[Dori Ephrat]

The audit statements have been revised

Comment 31

[Ben Wilson]

I reviewed SSLCOM Group’s CPS, v. 1.3, dated July 2019
Downloaded here https://bugzilla.mozilla.org/attachment.cgi?id=9079230 and from https://www.sslcomgroup.com/repository here: https://c9881787-42f4-4380-9be9-86127682c182.filesusr.com/ugd/e6d025_bc04855d3d454d52a86f95b0fb044a34.pdf

My initial comments and observations are as follows:

1.2. Document Name and Identification
Document is titled, “SSL Certificate Practice Statement” but then in section 1.3.1 is referred to as a “Certificate Policy”. If this a combined CP/CPS, then it should so state.
CPS complies with RFC 3647 framework – good
The CPS provides that “In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this CPS.” That is good.

1.3.2. Registration Authority
Mozilla Policy disallows delegation of domain name and IP address validation. This section states, “No Delegated third parties are allowed.” That is good.

1.4.2. Prohibited Usage
While not currently required by Mozilla Policy, this section does not say anything about prohibiting use of SSL/TLS certificates for traffic interception / MITM.

1.5.1 Organization administrating the document
Revision history indicates that the CPS was last edited July 13, 2019, which is shorter than a year, so that is good.

1.5.2. Contact person
As required by section 4.9.3 of the Baseline Requirements, this section is required to provide clear problem reporting and revocation request instructions through a readily available means. This section needs to be modified to do that.

1.6. Definitions and Acronyms
Definitions for Root CA and Online CA are identical: “The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.”

2.1. Legal Document Repositories
States that the CPS shall be reviewed annually for any updates and changes. However, Mozilla Policy requires that the CPS also be re-versioned, even if there are no updates or changes. Please make this correction to your language.

3.1 Naming
Somewhere in section 3.1 or one of its subsections in the CPS, you should acknowledge that internal names and reserved IP addresses are prohibited. (See BR Section 7.1.4.2.1)

3.1.1. Types of Names and 3.1.4 Rules of Interpretation
Not only must naming comply with X.500, but it must also comply with RFC 5280 and the CA/Browser Forum’s Baseline Requirements.

3.1.2. Meaning of Names
For SSL/TLS certificates, the CN is allowed (optional), but it can only contain information that is in one of the subjectAlternativeNames. The CPS should state this somewhere.

3.2.1. Private Key Possession and 6.1.1.3. Subscriber Key Pair Generation
Section 3.2.1 states “the private key will at no point in time be in the possession of the SSLCOM CA.” Section 6.1.1.3 states, “SSLCOM is not involved in the generation of subscriber keys.” That is good - these provisions meet Mozilla requirements that the CA does not generate the private key pairs of subscribers.

3.2.2.3. CAA Verification
Is this a method of domain validation? It seems confusing and doesn’t have a corresponding cross-reference to the Baseline Requirements.

3.2.3. Personal Identification
This section is confusing because the following methods appear to establish the identity of an organization more than they do a natural person:

1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition; OR
2. A third party database that is periodically updated and considered a Reliable Data Source; OR
3. A site visit by the CA or a third party who is acting as an agent for the CA; OR
4. An Attestation Letter.

3.2.4. Non Verified Subscriber Information
This section should be re-written to state something similar to: “The SSLCOM CA shall not include any non-verified individual or organizational information in the certificate.”

3.3. Identification and Authentication for Re-key Requests
There are a couple of unclear sentences: (1) “: A CSR shall be submitted. original, valid key.” (2) “Upon validation, a new Certificate key will be issued.”

4.2.2. CAA Record Processing
RFC 6844 has been replaced by RFC 8659.

4.3.2. Notification to Subscriber of Certificate issuance
This sentence has a few errors, including a wrong cross-reference. “Following verification of all required details in Application Request, the RA shall send a confirmation email to the Applicant, including a Random Value generated coded, as specified is section 3.2.4 above.”

4.6. Certificate Renewal
Section 4.2.1 of the Baseline Requirements allows SSLCOM to re-use verification information for renewal, but that use is limited to 825 days (“provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate”). (That period will likely be shortened in the future.)

4.7 Certificate Re-key
This section says, “Certificate Re-key is not supported.” But section 3.3 describes how to perform a re-key. This causes confusion.

4.9.1.1. Subscriber Certificate Revocation
Section 4.9.1.1 of the Baseline Requirements requires revocation within 24 hours and does not allow a generally worded delay in the 24-hour requirement for “confirming the Subscriber identity.” The Baseline Requirements also list 15 reasons to revoke a Subscriber’s certificate, but the CPS only lists 10. Also, in the Baseline Requirements, there are 9 reasons listed to revoke a subordinate CA, but the CPS only lists 5.

4.9.2. Who Can Request Revocation
The CPS should acknowledge that third Parties are entitled to submit a Certificate Problem Report under section 4.9.2 of the Baseline Requirements, and then additional information should be located in section 1.5.2 of the CPS.

4.9.5.2
This section needs to be made compliance with Section 4.9.5 of the Baseline Requirements, which states, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.” That is, for the 4 listed reasons, revocation must occur within 24 hours, and 5 days are allowed for the other 11 reasons.

4.9.9. On-line Revocation Availability and/or 4.10.1. Operational characteristics
One of these sections should state that OCSP responses are updated at least every 4 days with a maximum lifetime of 10 days. (Mozilla Root Store Policy, Section 6). https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation

5.7. Compromise and Disaster Recovery or 5.8. CA or RA Termination
The listing of components of the Business Continuity Plan is good.
However, in the event of a compromise or business termination, Mozilla and the other root store operators must be notified immediately. That should be added to your incident response procedures.

6.1.1.2. RA key Pair Generation
This section is blank. Blank sections are not allowed. See Item 5 in Mozilla Root Store Policy, Section 3.3. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses

6.3.2. Key Usage Periods
SSLCOM should consider amending the maximum certificate validity period for Subscribers to 397 days (in line with requirements coming into effect on 1-Sept-2020).

6.5.1. Specific computer security technical requirements
This section states that multi-factor authentication method is enforced for all accounts directly involved with certificate issuance. This is good.

6.7. Network Security Controls
SSLCOM should consider attesting to its compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements, https://cabforum.org/network-security-requirements/.

7.1.1. ROOT CA Certificate Profile and 7.1.2. ONLINE CA Certificate Profile:
The encoding for the issuer DN and the subject DN should be identical.
It appears that SSLCOM uses PrintableString and UTF8String (and not TeletexString).
The profile should also acknowledge that the CAs include the basicConstraints field, marked critical, where CA is TRUE.

7.1.3. Web Server Subscriber DV Certificate Profile
DV certificates are not allowed to have “surname and given-name” or “EmpNo. or ID No. or Passport No.”
The serverAuth EKU is required (not the Smartcard Logon EKU).
Note: No OV certificate profile was provided, only a DV certificate profile.

9.5. Intellectual Property Rights
According to section 3.3 of the Mozilla Root Store Policy, a Creative Commons License (Attribution-NoDerivs) is granted to the CPS. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses

The items above should be corrected by SSLCOM and then I will perform a second and more thorough review.

Comment 32

[Ben Wilson]

Also, in looking through the CPS and other information provided by SSLCOM Group, I noticed that websites under the domain "almostfreessl.com" aren't working even though they are listed throughout the CPS and are embedded in several places in certificates and in SSLCOM Group's inclusion request.

The domain "sslcomgroup.com" works. Although in section 4.2.2 of the CPS (CAA listing, there appears to be a typo in "sslcomgoup.com").

I got DNS errors for all of the following URLs:

www.almostfreessl.com/support/contactus

policy.almostfreessl.com/cps

crt.almostfreessl.com (Listed everywhere for all CA certificate downloads in the CPS, at sslcomgroup.com, and in the CCADB)

And, therefore, CRLs and OCSP don't work:

crl01.almostfreessl.com

crl02.almostfreessl.com

ocsp.almostfreessl.com (94.188.173.210) (OCSP timed out.)

The following certificate tests also failed:

https://certificate.revocationcheck.com/testvalid.tagim2.polimil.com (CRLs failed and OCSP timed out)

https://certificate.revocationcheck.com/testrevoked.tagim2.polimil.com ("the request for testrevoked.tagim2.polimil.com could not be completed... We could not load the certificate for testrevoked.tagim2.polimil.com, it might not exist or we could not reach the server, complete the TLS handshake, etc.")

https://certificate.revocationcheck.com/testexpired.tagim2.polimil.com (Issuer CA was “Fortinet CA”, not an SSLCOM CA)

These circumstances are considered very bad and do not bode well.

Comment 33

[Yosi Rosner]

Due to COVID-19 our server farm host provider has serious operation disability issues.
We are working to transfer our servers etc. to another server farm.
I will update when we finish the transfer.

Comment 34

[Ben Wilson]

Attachment: Expired Domain for AlmostFreeSSL.PNG

When I check the website, it says the domain, almostfreessl.com, has expired. Also, when I check crt.sh (https://crt.sh/?id=1372251186), it says there are ASN1 structure errors. (asn1: structure error: tags don't match (16 vs {class:0 tag:28 length:33 isCompound:true}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} CertificateList @2 [http://crl01.almostfreessl.com/Almost_Free_SSL_RootCA_G1.crl]
asn1: structure error: tags don't match (16 vs {class:0 tag:28 length:33 isCompound:true}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} CertificateList @2 [http://crl02.almostfreessl.com/Almost_Free_SSL_RootCA_G1.crl])

Comment 35

[Rob Stradling]

I just tried accessing both of those CRL URLs, to investigate why crt.sh is showing that error. Both URLs returned an HTML page instead of a CRL.

Comment 36

[Ben Wilson]

I am going to close this inclusion request on or about 30-October-2020 due to numerous problems with the application.