Common CA Database

Home | Policy | For CAs | For Root Stores | Resources

Field Types and Valid Values

This page explains how the various records and sections in the CCADB are best filled out, with some advice on how to create or obtain the data.

Table of Contents:

  1. Audit Information
  2. Auditor Information
  3. Formula Fields
  4. PEM Data
  5. Policies and Practices Information
  6. Revocation Information
  7. Uploading Documents

Audit Information

Field NameWhat to Enter
Audits Same as Parent Check this box if this certificate has the same audit information as the issuing certificate (or a subset). If you check this box, then do not enter data into the other fields in this section. If you need to add data to the other fields in this section, then uncheck this box.


There are 6 audit statements that may be provided:

  1. Standard Audit
  2. Network Security Audit
  3. TLS Baseline Requirements Audit
  4. TLS EV Guidelines Audit
  5. Code Signing Audit
  6. S/MIME Baseline Requirements Audit

For each applicable audit, the following information must be provided, and must meet the individual Root Store requirements and the requirements of section 5.1 of the CCADB Policy.

Field NameWhat to Enter
Audit Statement (Link) URL to the audit statement PDF.
WebTrust Seals: Enter the WebTrust Seal URL into this field. When you save your changes, the CCADB will automatically convert the Seal URL to the URL of the corresponding audit statement PDF. ETSI Auditor's URL: Enter the URL that points to the Audit Attestation Letter (AAL) that is stored on your ETSI auditor's website.
Audit Type Choose one of the provided options that most closely aligns with the type of audit; e.g. WebTrust or ETSI EN 319 411.
Audit Statement Date Date that the audit statement was signed.
Audit Period Start Date
Audit Period End Date
In a period‐of‐time audit, the Audit Period is the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.)
The period during which the CA issues certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.


Auditor Information

Field NameWhat to Enter
Auditor Find all Auditors known to the CCADB by clicking on the 'Auditors' report in the 'Custom Links' section in any root certificate, intermediate certiifcate, or case page. Contact your Root Store Operator if your auditor is not in this list.
To fill in the auditor's name, click on the pencil icon in the 'Auditor' field, then enter a string of two or more characters that you expect to be in your auditor's name and hit 'Return'. Click on your auditor's name, then click on the 'Save' button.
Auditor Location Find all Auditor Locations known to the CCADB by clicking on the 'Auditors' report in the 'Custom Links' section in any root certificate, intermediate certiifcate, or case page. Contact your Root Store Operator if your auditor's location is not in this list.
To fill in the auditor's location, click on the pencil icon in the 'Auditor Location' field, then enter a string of two or more characters that you expect to be in your auditor's location and hit 'Return'. Click on your auditor's location, then click on the 'Save' button.


Auditor qualifications are verified and entered into the CCADB by a Root Store Operator. For example, Mozilla re-verifies auditor qualifications annually as described here.

Note: The CCADB considers the terms “intermediate” and “subordinate” synonymous.

Formula Fields

These are some of the fields that are automatically filled in by the CCADB and cannot be manually edited.

Field NameLogicUpdates
Derived Trust Bits
  • Set to empty when the certificate is expired or revoked.
  • Directly map to Extended Key Usage (EKU) values when the certificate's EKU is present and not empty.
  • If the EKU is empty or not present, then set "Derived Trust Bits" to the union of the trust-bits/EKUs that are on the parent root certificate for each root store that it is included in.
    • Check for doppelganger (same Subject+SPKI) root certificates, and if found, update the union to add the trust-bits/EKUs that are on the parent root certificate for each root store that it is included in (if not already in the union).
  • If this certificate has an intermediate certificate as its parent in the CCADB, then:
    • Create "List2" that consists of the parent certificate’s "Derived Trust Bits" unioned with the "Derived Trust Bits" of all of the parent certificate’s unexpired unrevoked doppelganger (same Subject+SPKI) certificates.
    • Remove anything from this certificate's "Derived Trust Bits" that is not in "List2".
When related fields are updated on a root or intermediate certificate record, a trigger method launches an asynchronous process that updates this field (if needed) for every certificate within that record's CCADB hierarchy.
EV SSL Capable
    For an intermediate certificate to be considered technically capable of issuing EV SSL certificates, all of the following have to be true for that certificate as well as the intermediate certificates that it chains up to.
  1. The certificate is not revoked and not expired.
  2. "Derived Trust Bits" field contains "Server Authentication"
  3. The root certificate that it chains up to is enabled for EV by at least one of the root stores that it is included in.
  4. "Policy Identifiers" field contains one or more of 2.23.140.1.1, 2.5.29.32.0, or any of the values in the ExtendedValidation.cpp OIDs field of the root certificate.
If the above check fails for a parent intermediate certificate, then look for doppelganger (same Subject+SPKI, not expired, not revoked) certificates and perform the check on any that are found.
When related fields are updated on a root or intermediate certificate record, a trigger method launches an asynchronous process that updates this field (if needed) for every certificate within that record's CCADB hierarchy.
Technically Constrained
  • Set to FALSE if the certificate does not contain an Extended Key Usage (EKU) extension.
  • Set to TRUE if the EKU does not contain id‐kp‐serverAuth or anyExtendedKeyUsage.
  • If the EKU contains id‐kp‐serverAuth, then set to TRUE if the certificate includes the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName. Otherwise set to FALSE.
Set when certificate PEM is imported into the CCADB.
Has Non-constrained Doppelganger? This field is set to TRUE when its "Technically Constrained" field is set to TRUE and there are doppelganger (same Subject+SPKI, not expired, not revoked) intermediate certificates that have Technically Constrained == FALSE. A batch program runs once per day to update this flag.


PEM Data

The CCADB accepts certificate information in the PEM format. PEM is a container format defined in RFCs 1421 to 1424. PEM actually means Privacy Enhanced Mail, but the container format it uses is a Base64 translation of X.509 ASN.1 keys.

For reference, here are a few OpenSSL commands that convert certificates from other formats into PEM.

  • openssl pkcs7 -in certificates.p7b -print_certs -out certificates.pem
  • openssl pkcs12 -in certificates.pfx -out certificates.pem -nodes
  • openssl x509 -inform der -in certificate.der -out certificate.pem

You may use the Certificate Viewer to verify that your certificate is in the correct PEM format.

Policies and Practices Information

Field NameWhat to Enter
CP/CPS Same as Parent Check this box if this certificate has the same CP/CPS information as the issuing certificate (or a subset). If you check this box, then do not enter data into the other fields in this section. If you need to add data to the other fields in this section, then uncheck this box.
Policy Documentation Notes about the documentation, such as which language the documents are in, or additional documents that need to be listed.
CA Document Repository URL to the document repository pertaining to this certificate.
Certificate Policy (CP) URL to the Certificate Policy (CP) pertaining to this certificate.
Certificate Practice Statement URL to the Certificate Practice Statement (CPS) pertaining to this certificate.


Revocation Information

Revocation Information For This Certificate

Field NameWhat to Enter
Revocation Status The CCADB Policy, says “If a subordinate CA certificate is revoked, the CCADB must be updated to mark it as revoked, including the reason for revocation, within seven calendar days of revocation.”
Date of Revocation Must match the revocation date indicated in the CRL.
RFC 5280 Revocation Reason Code Must match the revocation reason code indicated in the CRL.
Alternate CRL Only fill in this field when this certificate does not contain a CRL URL. Note that the BRs require intermediate certificates to contain CRL URLs.


Pertaining to Certificates Issued by this CA

Field NameWhat to Enter
Full CRL Issued By This CA Enter the URL to the full CRL for certificates issued by this CA.
JSON Array of Partitioned CRLs When there is no full CRL for certificates issued by this CA, provide a JSON array whose elements are URLs of partitioned, DER-encoded CRLs that when combined are the equivalent of a full CRL for certificates issued by this CA. The JSON array may omit obsolete partitioned CRLs whose scopes only include expired certificates.

Example:
[ "http://cdn.example/crl-1.crl", "http://cdn.example/crl-2.crl" ]


Uploading Documents

Many CCADB fields require URLs to documents. In general, CP/CPS and Audit information should be provided on the CA Owner’s website, subordinate CA Owner’s website, or the auditor’s website. However, if for some reason this is not possible, you can use the Bugzilla bug-tracking system to store the documents and get a URL for use in the CCADB as follows:

  1. If you don’t already have a Bugzilla account, create one for yourself.
  2. Search to see if there is already a Bugzilla Bug for your CA that you can attach your documents to.
  3. If one does not exist for your CA, create one.
    • Enter Summary as: “Documents for <your CA’s name>”
    • Enter Description as: “The purpose of this bug is to store documents related to the root and intermediate certificates for <your CA’s name>.”
  4. Attach the document to the bug using the attachment mechanism.
  5. Copy and paste the link to the attachment into the corresponding field in the CCADB.
  6. Repeat steps 4 and 5 as needed, using the same Bugzilla bug.