CA/Subordinate CA Checklist

Subordinate CAs Operated by Third Parties For Internal Use

When your root signs subordinate CAs for enterprises/companies who operate the sub-CA for their own use, the following information needs to be publicly available.

1. General description of the sub-CAs operated by third parties.
2. The Certificate Practice Statement and Policy that the sub-CAs are required to follow.
3. Requirements (technical and contractual) for sub-CAs in regards to whether or not sub-CAs are constrained to issue certificates only within certain domains, and whether or not sub-CAs can create their own subordinates.
4. Requirements for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy.
   • domain ownership/control
   • email address ownership/control
   • digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate
5. Description of audit requirements for sub-CAs
   • Whether or not the root CA audit includes the sub-CAs.
   • Who can perform the audits for sub-CAs.
   • Frequency of the audits for sub-CAs.

Subordinate CAs Operated by Third Parties For External Use

This section applies when your root signs subordinate CAs for companies who use the sub-CA to sign other sub-CAs or certificates for other companies or individuals not affiliated with their company. For instance, this section applies to you if your root issues sub-CAs that are used by Certificate Service Providers (CSP).

In addition to the information listed above, you will also need to provide the following information for each CSP.

1. Sub-CA Company Name
2. Sub-CA Corporate URL
3. CA hierarchy under the sub-CA.
4. Sub-CA CP/CPS Links
5. The section numbers and text (in English) in the CP/CPS that demonstrate that reasonable measures are taken to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy.
   • domain ownership/control
   • email address ownership/control
   • digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate
6. Identify if the SSL certificates chaining up to this root are DV and/or OV. Some of the potentially problematic practices, only apply to DV certificates.
   • DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.
   • OV: Both the Organization and the ownership/control of the Domain Name are verified.
7. Review the CP/CPS for potentially problematic practices, as per Potentially Problematic Practices. Provide further info when a potentially problematic practice is found.
8. If the root CA audit does not include this sub-CA, then for this sub-CA provide a publishable statement or letter from an auditor that meets the requirements of sections 8, 9, and 10 of our Mozilla CA certificate policy.
9. Provide information about the CRL update frequency for end-entity certificates. There should be a statement in the CP/CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 36 hours.