Open Bug 1532426 Opened 1 year ago Updated 5 months ago

Add SSLCOM to your trusted root CA cert list

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: dori, Assigned: wthayer)

References

Details

(Whiteboard: [ca-cps-review] - KW 2019-09-16)

Attachments

(4 files, 3 obsolete files)

31.36 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
1.64 MB, application/pdf
Details
660.06 KB, application/pdf
Details
692.78 KB, application/pdf
Details
Attached file SSLCOM WebTrust CA Audit Report.pdf (obsolete) —

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

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.

Attached file SSLCOM WebTrust SSL Audit Report.pdf (obsolete) —

attached is the missing SSL audit report

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

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

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.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - KW 2019-04-01 - Comment #5
Duplicate of this bug: 1535673

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

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.

Whiteboard: [ca-verifying] - KW 2019-04-01 - Comment #5 → [ca-verifying] - KW 2019-04-24 - Comment #7

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

AllmostfreeSSL BR self assessment

Attached file SSLCom CPS v1.2.pdf (obsolete) —

latest CPS

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

Whiteboard: [ca-verifying] - KW 2019-04-24 - Comment #7 → [ca-verifying] - KW 2019-06-19 - Comment #12

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

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

Flags: needinfo?(kwilson)

(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.

Flags: needinfo?(kwilson)
Attached file SSLCom CPS v1.3.pdf
Attachment #9048308 - Attachment is obsolete: true
Attachment #9048315 - Attachment is obsolete: true
Attachment #9072354 - Attachment is obsolete: true
Attached file SSLCOM WebTrust CA.pdf

(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

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

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

Whiteboard: [ca-verifying] - KW 2019-06-19 - Comment #12 → [ca-verifying] - KW 2019-09-12 - Comment #21

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

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.

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-09-12 - Comment #21 → [ca-cps-review] - KW 2019-09-16
You need to log in before you can comment on or make changes to this bug.