CA:SalesforceCommunity

From MozillaWiki
Jump to: navigation, search

Common CA Database

Mozilla's CA Program has its own instance of Salesforce for managing the CA Program data. This is referred to as the Common CA Database (CCADB), and is also known as the CA Community in Salesforce.

The CCADB enables CAs to directly provide the data for all of the publicly disclosed and audited subordinate CAs chaining up to root certificates in Mozilla's program, and to also directly provide data about their revoked intermediate certificates. A Primary Point of Contact for each included CA will be given a Salesforce CA Communitylicense, so that each of the CAs in Mozilla's program can input, access, and update their intermediate certificate data directly in SalesForce.

Mozilla plans to add automation that will use the intermediate certificate data in Salesforce to create a whitelist of non-technically-constrained intermediate certificates chaining up to root certificates in Mozilla's program. Mozilla also plans to add automation to use the revoked intermediate certificate data in Salesforce to update OneCRL.

We will be publishing automatically-generated reports for the intermediate certificate data, and our goal is to make it as easy as possible for each CA to enter and maintain this data.

CA Responsibilities

With respect to the Common CA Database (CCADB), here is what Mozilla requires of CAs:

  1. Login to the CCADB on a regular basis to ensure that the information for your CA is current and accurate.
    • CAs must enter the data corresponding to their non-technically-constrained intermediate certificates before those intermediate certificates begin issuing publicly-trusted certificates. See details below.
    • If information about a root certificate needs to be updated, the CA should contact the corresponding root store operator, because only root store operators may modify root certificate data in the CCADB.
    • If contact information needs to be updated, the CA should contact one of the participating root store operators, because only root store operators may modify contact data in the CCADB.
  2. CAs must enter and maintain the records corresponding to their non-technically-constrained intermediate certificates as described in this page.
  3. CAs must enter and maintain the records corresponding to their revoked intermediate certificates as described in this page.

Request a license

A Primary Point of Contact for each included CA will be given a Salesforce CA Communitylicense. If you believe that you should have a Salesforce CA Community license but you have not received one, then please send email to certificates@mozilla.org with your name and the name of the CA you represent.

Login to Common CA Database

  1. https://mozillacacommunity.force.com/
  2. Enter your Username; the email address for which your Community User License was issued
  3. Enter the Password that you set up during first access
  4. Click on the "Log in to CA Community" button

If you are the Primary Point of Contact for an included CA, you may request a CA Community Salesforce license or request that your password be reset by following the instructions above.

Navigate the Common CA Database

Upon initial login you will see a row with three tabs:

  1. CA Owners/Certificates
    • Click on "CA Owners/Certificates" tab, then in "View:" select "Community User's CA Owners/Root Certs" and click on "Go!". This will list the CA Owner and all of the root certificates associated with your account. Click on the "CA Owner/Certificate Name" to view the record. Within the record you will see an Account Hierarchy section, where you can click on each root or intermediate certificate record to view the data.
    • Click on "CA Owners/Certificates" tab, then in "View:" select "All Included CA Owners" and click on "Go!". You will see all of the CAs who have root certificates included in the NSS root store. Click on the CA Owner Name, to view the record.
    • Click on "CA Owners/Certificates" tab, then in "View:" select "Community User's Intermediate Certs" and click on "Go!". This will list the intermediate certificates associated with your account. Click on the "CA Owner/Certificate Name" to view the record.
  2. Contacts
    • Click on "Contacts" tab, then in "View:" select "All Contacts" and click on "Go!". Click on the Name to view the contact record.
    • Note: If any of the contact information for your CA needs to be updated, then send email to Kathleen. CA Community licenses do not enable the CA to directly modify their contact data.
  3. Reports
    • Click on "Reports" tab, then click on the "CA Community Reports" link along the left column, then click on one of the reports in the list. Whenever you click on the "Reports" tab it will list the reports that you have recently viewed. You will need to click on the "CA Community Reports" link to see all of the reports that are available to you.

Important Notes:

  • Each Owner/Certificate record has a "CA Owner/Certificate Name" field. For a certificate record, the value of this field is usually the Certificate Subject Common Name of the certificate. For a CA Owner record, this field displays the CA's name. (We cannot change the title of the field in the page, due to the way we are using it in Salesforce.)
  • Each Certificate record has a "Parent CA Owner/Certificate" field. For an intermediate certificate record the value of the field should be the Certificate Issuer Common Name. For a root certificate record the value of the field will be the name of the CA owner. (We cannot change the title of the field in the page, due to the way we are using it in Salesforce.)
  • CA Community Users cannot modify the records for: Owner, Root Certificate, and Contact. Only the CA Certificates Module Owner and Peers can modify these records.
  • CA Community Users can only modify the intermediate certificate records for their CA.
  • The Intermediate certificate records have a Status field that may not be modified by CAs.
  • The certificate detail fields that are extracted from the PEM data cannot be edited. To change those values, the new PEM data needs to be provided via the 'Add/Update PEM Info' button.
  • PEM data must be provided for every intermediate certificate (chaining up to a root certificate in Mozilla's program) that is not Technically Constrained via Extended Key Usage and Name Constraint settings. Policy documentation and audit statements must also be provided for these non-technically-constrained intermediate certificates, as per section 10 of Mozilla's CA Certificate Inclusion Policy.

View Reports in Salesforce

Click on "Reports" tab, then click on the "CA Community Reports" link along the left column, then click on one of the reports in the list. Whenever you click on the "Reports" tab it will list the reports that you have recently viewed. You will need to click on the "CA Community Reports" link to see all of the reports that are available to you. The reports are:

  • All Public Intermediate Certs -- All Public (non-revoked) intermediate certificates that have been entered into Salesforce.
  • All Revoked Intermediate Certs -- All revoked intermediate certificates that have been entered into Salesforce.
  • My Blank Intermediate Certs -- The intermediate cert records that you have entered that have the default value, "<Fill in CA Owner/Cert name>", certificate name. This means that you need to enter the certificate's PEM data to update the record.
    • Click on one of the links in the Certificate Name column in the report to view the certificate record.
  • My Included Root Certs -- The currently-included root certificates for your CA.
  • My Public Intermediate Certs -- The Public (non-revoked) intermediate certificates that have been entered into Salesforce for your CA.
  • My Revoked Intermediate Certs -- The revoked intermediate certificates that have been entered into Salesforce for your CA.

Data that CAs can Add/Modify

With a Salesforce CA Community license, CAs can view root and intermediate certificate data for all of the CAs in Salesforce.

  • CAs can modify records for:
  • CAs cannot modify records for:
    • Root certificate data. All changes to root certificates must go through the root store operator's root inclusion/change process. If you need to update CP/CPS, audit, or Point of Contact data for your root certificate(s) send email to the root store operator.
    • Intermediate certificate data chaining up to root certificates that they do not own.

Which intermediate certificate data should CAs add to Salesforce?

CAs must add records for:

  • All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.
    • Including every intermediate certificate (chaining up to a root certificate in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage and Name Constraint settings.
    • Intermediate certificates are considered to be technically constrained, and do not need to be added to the CCADB if:
      • The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or
      • The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or
      • The root certificate is not enabled with the Websites trust bit.
  • Revoked certificates that were capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.

When the same exact intermediate certificate chains up to two included root certificates, the certificate data only needs to be included in Salesforce once.

  • For root certificate (rootA) that is cross-signed by another included root certificate (rootB) that has the Websites trust bit enabled, the intermediate certificates chaining up to rootA only need to be entered into the CCADB once.
    • The cross-certificates for rootA that are signed by rootB must be entered into Salesforce such that their records chain up to rootB.
    • If rootA is included and has the Websites trust bit enabled, then its intermediate certificates should be entered into Salesforce such that their records chain directly to rootA.
    • If rootA has been removed from NSS or does not have the Websites trust bit enabled, then its intermediate certificates must be entered into Salesforce such that their records chain to rootB.
    • If rootA and rootB are owned by different CAs, then both CAs are responsible for ensuring that the data for all of their non-technically-constrained intermediate certificates are appropriately entered into Salesforce.

CAs should not add records for:

Add Intermediate Certificate Data to Salesforce

To add an intermediate certificate:

  1. Find the root certificate that signed the intermediate certificate
    • Type the name of your CA or the name of the root certificate into the Search bar at the top of the window. Click on the name of the root certificate to open the record.
    • Or click on "CA Owners/Certificates" tab, then in "View:" select "Community User's CA Owners/Root Certs" and click on "Go!". Click on the name of the root certificate to open the record.
  2. Click on the "New Intermediate Cert" button. This will create a new record for an intermediate cert chaining up to the certificate record you were just viewing.
  3. Click on the "Add/Update PEM Info" button. This will display a window in which you will paste in the PEM data for the intermediate certificate.
  4. Copy and paste the PEM data into the window. Starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----
  5. Click on "Validate PEM Info" button. This will invoke a program that will try to parse the PEM data and extract certain information.
  6. If the cert check is successful, then click on the "Update Intermediate Cert" button.
    • If the cert check was not successful, then click on the "Cancel" button. Check that the PEM data is correct and try again, by clicking on the "Add/Update PEM Info" button and copy-pasting the data in, etc. If it still fails, then send email to Kathleen with the PEM data.
  7. In the intermediate certificate record you will see that the cert data has been filled in.
    • Review the filled-in information (Issuer and Subject information, and SHA-1 Fingerprint) to ensure it is the data you expected. If the data is not what you expected, then check that you have the correct PEM data for the certificate you intended to add. Check the section titled "PEM Information..." to make sure the PEM is as you intended. There should not be extra characters before or after the PEM, and the PEM data should not have extra line feeds in it. You may go through the "Add/Update PEM Info" process as many times as needed.
  8. Fill in the information in the "Audit Information" and "Policies and Practices Information" sections. The audits and policies must cover the intermediate certificate.
    • If the information is the same as for the issuing (parent) certificate, then click on the "Edit" button, and check on the "... Same as Parent" check-boxes ("CP/CPS Same as Parent" and "Audits Same as Parent"), then click on the "Save" button.
    • If the information has some differences from the issuing (parent) certificate, then click on the "Edit" button to enter the audit and policy information. Be sure to click on the "Save" button afterward.

Notes:

  • To add an intermediate certificate that is signed by an intermediate certificate (rather than a root certificate), the same instructions apply except that rather than finding the root certificate, find the intermediate certificate and then click on the "New Intermediate Cert" button.
  • The "Clone" button will not copy the cert data (which is extracted from PEM data); it will only copy the other fields such as the policy documentation and audit information.
  • PEM data must be provided for every intermediate certificate (chaining up to a root certificate in Mozilla's program) that is not Technically Constrained via Extended Key Usage and Name Constraint settings. Policy documentation and audit statements must also be provided for these non-technically-constrained intermediate certificates, as per section 10 of Mozilla's CA Certificate Inclusion Policy.
  • Automated Data Import is available for CAs who have a very large number of intermediate certificates to be added.

Clone

The "Clone" button is useful when you are entering intermediate certificate data, and you have intermediate certificates that share the same CP, CPS, and audit statements, then you can use the "Clone" button to save time. The recommended procedure is as follows.

  1. Enter the data for one intermediate certificate following the instructions above.
  2. Make sure the "Audit Information" and "Policies and Practices Information" sections are completely and correctly filled in and saved. Or that the "CP/CPS Same as Parent" and "Audits Same as Parent" checkboxes are set.
  3. Click on the "Clone" button. This will create a new intermediate certificate, copying the "Parent CA Owner/Certificate" field and the "Audit Information" and "Policies and Practices Information" sections.
  4. Click on the "Add/Update PEM info" button, and enter the PEM data for the intermediate certificate data you are adding. Starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----
  5. Click on the "Validate PEM Info" and "Update Intermediate Cert" buttons. The data for the intermediate certificate will be automatically filled in.
  6. If the intermediate certificate has a different Issuer than the cert you had cloned, then click on the "Edit" button, change the "Parent CA Owner/Certificate" to the correct value (which you can copy from the Cert Issuer Common Name field in the page), and click on the "Save" button.

Policies and Practices Information

Field Name What 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.

Documents

According to Mozilla's CA Certificate Inclusion Policy, section 10: "For a certificate to be considered publicly disclosed and audited, the following information MUST be provided: ... corresponding Certificate Policy or Certification Practice Statement used by the subordinate CA; and Annual public attestation of conformance to the stated certificate verification requirements and other operational criteria by a competent independent party or parties with access to the details of the subordinate CA’s internal operations."

The CP/CPS and Audit information for publicly-disclosed and audited intermediate certificates should be provided on the subordinate CA's website, or the CA's website. However, if needed, you can use Bugzilla to provide the CP/CPS and Audit documents as follows.

  1. Create a Bugzilla Bug
    • If you don't already have a Bugzilla account, create an account for yourself.
      • Note that you must supply an email address when creating an account. Be sure to use an email address that you regularly monitor, so you will be notified whenever a Bugzilla Bug that you create is modified.
    • Create a Bugzilla Bug -- This link will create a bug with the following fields set:
      • Product: mozilla.org
      • Component: CA Certificates
      • Version: Other
      • Severity: enhancement
      • Platform: All
      • OS: All
      • Summary: Documents for [your CA's name] intermediate certificates
      • Description: The purpose of this bug is to store documents related to the publicly disclosed and audited intermediate certificates chaining up to [your CA's name] root certificates.
    • If needed, you can manually create the bug: Go to the Bug Entry Page, click on Other Products, and select mozilla.org under Other. Then select the fields as listed above.
  2. Close the Bug as "Resolved", "WORKSFORME", with a comment that the bug is for storing documentation.
  3. Attach the document to the bug
  4. Copy-and-paste the link to the Bugzilla Bug attachment into the corresponding field in Salesforce
  5. Repeat steps 3 and 4 as needed, using the same Bugzilla Bug.

Audit Information

Field Name What 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.
Standard Audit URL to an auditor's statement that the operation of this certificate has been audited according to one of:
  • ETSI TS 101 456 V1.4.3 or later (only applicable to non-SSL certs)
  • ETSI TS 102 042 V2.3.1 or later
  • WebTrust Principles and Criteria for Certification Authorities v2.0 or later

Note: See "Documents" section above if there is no public URL to the audit statement.

Standard Audit Type One of:
  • WebTrust
  • ETSI EN 319 411
  • ETSI TS 101 456
  • ETSI TS 102 042
Standard Audit Statement Date Date that the audit statement was signed.
BR Audit URL to a corresponding Baseline Requirements audit statement. Only required if the root certificate has the Websites trust bit enabled, and this certificate is capable of issuing SSL/TLS certificates.
BR Audit Type One of
  • WebTrust
  • ETSI EN 319 411
  • ETSI TS 102 042
BR Audit Statement Date Date that the BR audit statement was signed.
EV Audit URL to a corresponding EV audit statement. Only required if the root certificate has EV-treatment, and this certificate is capable of issuing EV SSL/TLS certificates.
EV Audit Type One of
  • WebTrust
  • ETSI EN 319 411
  • ETSI TS 102 042
EV Audit Statement Date Date that the EV audit statement was signed.
Auditor The Auditor's name
Auditor Website URL to the auditor's website, or a site showing their affiliation, accreditation, or qualifications
Auditor Qualifications URL to an attestation of the auditor's qualifications, such as http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx for WebTrust. For ETSI if you need help finding the URL, there are some useful links in section 5 of https://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx
Management Assertions By The name (in English) of the organization who made the management assertions for the Standard Audit. i.e. The name of the organization that validates the data to be included in certificates signed by this issuer.

Mass Update Audit/CP/CPS Data

The "Mass Update Audit/CP/CPS Data" button may be used to apply the same changes to other intermediate certificates signed by the same parent certificate. The certificate you are viewing when you click on the Mass Update button will be treated as the source. The program will then find all of the intermediate certs that are signed by the same parent cert and have different CP/CPS/Audit data. For each target certificate, you can select "Yes" in the sections that you want to copy from the source certificate, then click on "Next Target Cert" to move onto the next one.

This button may be used as follows.

  1. Update the "Audit Information" and "Policies and Practices Information" sections for one certificate, and Save the changes. Note that Mass Update is not allowed when 'Audits Same as Parent' and 'CP/CPS Same as Parent' are true.
  2. Click on the "Mass Update Audit/CP/CPS Data" button. This button will look for all of the certificates signed by the same parent certificate, and do the following...
    • The certificate you were viewing when you clicked on the "Mass Update" button will be treated as the "Source".
    • If the "Target" certificate has different Audit or Policy information than the Source, then a window will display the Audit and Policy information for both certificates side-by-side, and the differences will be shown in blue text.
    • If you want to update the Target certificate to have the same Audit or Policy information as the Source, then click on the "Yes" button in each section. Otherwise, click on the "Next Target Cert" button to continue to the next certificate.
    • If you click on the "Exit" button, you can re-start the process later without having to go through all of the certs that you already updated -- Each time you click on the Mass Update button, it will only show the sibling certificates with different Audit and Policy information.

Add Revoked Intermediate Certificate Data to Salesforce

Mozilla has implemented a revocation list push mechanism in Firefox called OneCRL, which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.

If the revocation of an intermediate certificate is due to a security concern, send email to security@mozilla.org. Otherwise, enter the revoked intermediate certificate information into the CCADB as described below. Then a Mozilla representative will verify the revoked intermediate certificate data, and update the 'OneCRL Status' to "Ready to Add". Then a Mozilla process will cause the revoked intermediate certificate data to be added to OneCRL. The Mozilla representative will follow up to ensure the data has been added to OneCRL, and then will update the record in the CCADB to change the 'OneCRL Status' to "Added to OneCRL".

The best way to add revoked intermediate certificate data to the CCADB is to first add the intermediate certificate record, and then mark the record as Revoked. This is the way all intermediate certificate revocations must be entered unless the certificate was Technically Constrained via Extended Key Usage and Name Constraint settings.

To add a revoked intermediate certificate, or to mark an intermediate certificate in an existing record as revoked:

  1. Add the intermediate certificate to the CCADB, if it has not already been added
    • Search for the root certificate that signed the revoked intermediate certificate
    • Click on the "New Intermediate Cert" button at the top of the page showing the root certificate information
    • Click on the "Add/Update PEM Info" button at the top of the page for the newly created intermediate certificate record
    • Provide the remaining information about the revoked intermediate certificate, such as policy and audit documentation as appropriate
  2. Find the intermediate certificate record, if you are not already viewing it
    • Copy-and-paste the SHA-1 or SHA-256 Fingerprint of the intermediate certificate, or type the name of the intermediate certificate into the Search bar at the top of the window. Click on the name of the intermediate certificate to open the record.
    • Or click on "CA Owners/Certificates" tab, then in "View:" select "Community User's Intermediate Certs" and click on "Go!". Click on the name of the intermediate certificate to open the record.
  3. Click on "Edit"
  4. Click on the "Revocation Status" field and select "Revoked".
  5. Enter the "Date of Revocation"
  6. Click on the "RFC 5280 Revocation Reason Code" field and select the corresponding revocation reason.
  7. Click on "Save" button

If the revoked intermediate certificate was Technically Constrained via Extended Key Usage and Name Constraint settings, but you would still like to add it to OneCRL and you are unable to provide the PEM data for the certificate, then send email to Kathleen with the following information:

  • Certificate Issuer Field
  • Certificate Subject Field
  • Certificate Serial Number
  • OCSP URL linking to the OCSP response for that serial number
  • CRL URL linking to the CRL that contains that serial number
  • Valid To (GMT) -- notAfter date of the revoked certificate

Required Annual Updates

According to Mozilla's CA Certificate Policy and the CA/Browser Forum's Baseline Requirements, CAs must provide the following updated information annually:

  1. Statement of attestation of the CA's conformance to the stated verification requirements and other operational criteria by a competent independent party or parties, as outlined in Mozilla's CA Certificate Policy.
  2. Links to the CA's current Certificate Policy or Certification Practice Statement document(s) or equivalent disclosure document(s) related to the CA's root certificate(s) included in Mozilla's program.
    • According to section 2.3 of the CA/Browser Forum's Baseline Requirements: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."
  3. If the CA's root certificate has the Websites trust bit set, then URLs to test web pages as described in section 2.2 of the CA/Browser Forum's Baseline Requirements: "At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."

How To Provide Annual Updates

Updating Root Certificate Data

Instructions for CAs to provide their annual updates via the Common CA Database (CCADB) for their included root certificates are here:

Updating Intermediate Certificate Data

CAs directly update the intermediate certificate records to provide current audit and policy information, as follows:

  1. Login to the CCADB
  2. Find the intermediate certificate record that needs to be updated. Here are three ways to find the record:
    • At the top of the CCADB window, paste in the SHA-1 or SHA-256 Fingerprint for the certificate. Then click on the name of the intermediate certificate in the resulting list.
    • Click on the 'Reports' tab, then click on "CA Community Reports" along the left column, then click on the "My Public Intermediate Certs" report.
      • The first column in the report will indicate if audit statements and/or policy documents are missing for an intermediate certificate record.
    • Click on the 'CA Owners/Certificates' tab, then in "View:" select "Community User's Intermediate Certs" and click on "Go!". This will list the intermediate certificates associated with your account.
  3. For each intermediate certificate record, make sure the audit information is provided.
    • If the intermediate certificate is audited as part of its parent certificate's audit, then check the "Audits Same as Parent" checkbox.
    • Otherwise provide the relevant audit information
  4. For each intermediate certificate record, make sure the policy documentation is provided.
    • If the policies regarding the intermediate certificate are included in the CP/CPS of its parent certificate, then check the "CP/CPS Same as Parent" checkbox.
    • Otherwise provide the relevant CP/CPS information

More Frequent Updates

According to Mozilla's CA Certificate Policy, CAs must notify Mozilla whenever:

  • The CA's policies and business practices change in regards to verification procedures for issuing certificates, when the ownership control of the CA’s certificate(s) changes, or when ownership control of the CA’s operations changes.
  • The CA's primary representatives for their included root certificate(s) changes.

CAs are also required to notify Mozilla via the Common CA Database (CCADB) when:

Audit Archive

As of December 13, 2016, audit statements for root certificates in the Common CA Database are archived. The CCADB will regularly run a program to determine which audit statement links have been updated, and download the pdf file as a permanent record.
To see a report of all File Archive records: Click on "Reports" tab, then click on the "CA Community Reports" link along the left column, then click on the "List of All File Archive Records" report.
To view audit archives for a particular CA:

  • Find the CA's Owner record. You may type in part of the CA's name, and use the '*' character, in the 'Search' bar at the top of the CCADB window (next to 'mozilla'). Or, you can click on "CA Owners/Certificates" tab, then in "View:" select "All CA Owners" and click on "Go!". Click on the "CA Owner/Certificate Name" to view the record.
  • Within the record scroll down to the "File Archive" section, to see the File Archives associated with that CA Owner.
    • "External Link" is the URL to the audit statement on the CA's website or in Bugzilla, and "Internal Link" is the link to same file stored within Salesforce.

Notes:

  • Currently the audit archive records may only be edited by a root store operator, so contact Kathleen if your audit archive records need to be updated.
  • Audit period dates were not previously stored in the CCADB, so audit period dates are currently empty in the audit archive records.
  • A new "Audit Archive" section has also been added to Root Certificate Records. This shows the corresponding "Internal Link" and the archive status for the audit statements in that record. When one of the audit statement links is changed, the corresponding audit archive status will be changed to "Not Processed", and will be updated the next time the File Archive program is run.

Delete a Record

In the near future, we plan to add custom code and a button to allow you to delete a record that you created.

In the meantime, if you need to delete a record that you added, please notify Kathleen and provide the values of the following Salesforce fields for each of the records to delete.

  • CA Owner/Certificate Name
  • Parent CA Owner/Certificate

View Published Reports