The information for this root inclusion request is available at the following URL.
Search for the word NEED to see where further information must be provided by the CA.
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.
Complete BR Self Assessment (https://wiki.mozilla.org/CA/BR_Self-Assessment) and attach it to this bug.
Full compliance with the CA/Browser Forum's Baseline Requirements includes this requirement
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.
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":
WebTrust BR Readiness audit for "SSLCom Root G1":
WebTrust CA Readiness audit for "Almost Free SSL RootCA G1"
WebTrust BR Readiness audit for "Almost Free SSL RootCA G1"
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?
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.
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.
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.
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
Add records for the existing intermediate certs to the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data
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.