Submitting Annual Updates
All CAs are required to update the audit, CP, CPS and test website information for their certificate hierarchies at least annually.
CAs in the CCADB are organized into hierarchies. Each CA Owner has children nodes that are Root Certificate records, Root Certificate records have children nodes that are Intermediate Certificate records, and Intermediate Certificate records have children nodes that are Intermediate Certificate records.
Records and Cases are also organized in hierarchies, similar in concept to the CA hierarchies. CAs will create an Audit Case for a particular set of audits (e.g. WebTrust CA, WebTrust BR, and WebTrust EV). Then the CA will create corresponding Root Cases to tell the CCADB which Root Certificate records those audit statements apply to.
Please have the following information prepared before you begin entering your annual update into the CCADB.
- Links to your audit statements in PDF format.
- Links to your CP/CPS documents in PDF format.
- CP/CPS documents must be updated each year, with a revised version number even if there are no other changes.
- Links to 3 Test websites (valid, expired, and revoked) for each root
certificate that has the TLS/SSL trust bit enabled.
- The existence of these websites is a requirement of the BRs, section 2.2.
- valid = unexpired and unrevoked
- expired = notAfter less than the current day, and unrevoked
- revoked = unexpired, but present in either/both of the CRL and OCSP responder
All audit, CP and CPS documents must:
- Have links which change each year, so that the audit archiving process will pick up the new version of the files.
- Be PDF files smaller than 25MB.
- Be in English.
If you don’t have a good place to put audit, CP and CPS documents, you can use Bugzilla.
- Login to the CCADB.
- There are two ways to create an Audit Case to provide your annual updates.
- Option 1) Click on “Cases” tab, then click on the ‘Create New Case’ button.
- Option 2) Navigate to the CA Owner Record for your CA.
- 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” of your CA’s Owner record.
- Scroll down to the ‘Cases’ section.
- At the top of the page, just above “CA Owner/Certificate Detail” there are links to each of the sections, so you can click on the “Cases” link to go to that section.
- Click on the ‘New Case’ button.
- Click on the ‘Submit’ button to create the new ‘Audit Case’.
- For our use, the ‘Submit’ button is the ‘Save’ button. (Salesforce doesn’t currently let us change the name of this particular button.)
- The ‘Subject’ will be automatically filled in when you click on the ‘Submit’ button, so leave it blank to begin with. You can change it later if needed.
- The ‘Recognized CAA Domains’ and ‘Problem Reporting Mechanism’ fields will be automatically filled in when you click on the ‘Submit’ button, so leave them blank to begin with. You can change them later if needed.
- Click on the ‘Edit’ button and enter the audit and CP/CPS information, then click on the ‘Submit’ button. You may click on ‘Edit’ and ‘Submit’ as many times as you need to get all of your information entered.
- After you have provided the audit and CP/CPS information, you will need to tell us which root certificates are covered by these audits.
- In the ‘Audit Case’ page, scroll down to the ‘Custom Links’ section and click on “List All Root Certs for This CA”. That will pop up another window that you may find useful for the next steps. Drag the window to the side, and continue with the next step.
- In the ‘Audit Case’ page, scroll down to the ‘Root Cases’ section.
- At the top of the page, just above the ‘Edit’ button there are links to each of the sections, so you can click on the “Root Cases” link to go to that section.
- Click on the ‘Add Root Cert For This Audit Info’ button to start a new Root Case.
- In the Root Case page, identify a root certificate that is covered in the
audit statements. You will need to create a new Root Case for each root
certificate that is covered by the audit statements.
- Click on the search icon next to the ‘Included Certificate’ field.
- Default list in Search shows recently viewed records. Be sure to enter the beginning of your cert name followed by asterisk (e.g. A*), and click on the ‘Go!’ button.
- Alternatively, you can type one of the words in the name of the root certificate, and click on the ‘Go!’ button.
- You will only be able to find root certificate records that chain up to your CA Owner record.
- Select one of the root certificates that is covered by the audit statements.
- Click on the search icon next to the ‘Included Certificate’ field.
- In the ‘Select all that apply to the included Root’ section, click on the appropriate boxes to show which audit statements cover the selected root certificate.
- Click on the ‘Save’ button.
- If the root certificate can validate TLS/SSL certificates, then you need
to also provide the URLs to the test websites. If the root certificate is
enabled for EV treatment, then the TLS/SSL certs for the test websites must
also be EV.
- Click on the ‘Edit’ button in the Root Case
- Enter the URLs to the test websites (valid, expired, and revoked)
- Click on the ‘Save’ button
- You may click on the ‘Edit’ and ‘Save’ buttons as many times as you need to get the necessary information filled in.
- Click on the ‘Case No’ to go back to the main ‘Audit Case’ page.
- Click on the ‘Add Root Cert For This Audit Info’ button and repeat the above steps to add as many Root Cases as needed, corresponding to the root certificates that are covered in the audit statements.
- Check that the information in the ‘Recognized CAA Domains’ and ‘Problem
Reporting Mechanism’ fields is current and of the correct format.
- ‘Recognized CAA Domains’ should be a comma-separated list of domain names recognized in a CAA record’s ‘issue’ and ‘issuewild’ property tags as permitting issuance under this root certificate.
- ‘Problem Reporting Mechanism’ should provide brief instructions for reporting suspected misissuance, private key compromise, information inaccuracy or other types of problem relating to certificates issued under this root certificate.
Before starting this process, it may be helpful to open another window showing your CA’s Account Hierarchy, so you can easily see which root certificates need to be accounted for in the audit statements. Navigate to your CA Owner record or any of your root or intermediate cert records, go to the ‘Account Hierarchy’ section, and right-click on any of the record names and ‘Open Link in New Window’.
In the Root Case page, when you click on the search icon next to the ‘Included Certificate’ field, the default list will be the records that you recently viewed.
What Happens Next?
After you create the Audit Case and corresponding Root Cases, a root store operator will review and verify the information. For your information, here’s what they verify:
- The Auditor is an independent and qualified auditor, and that the provided “Auditor Website” provides sufficient information about the auditor.
- The website provided for “Auditor Qualifications” is an acceptable authority, and that the Auditor is listed on that website as authorized for the country in which the Auditor’s offices are located.
- The name in the “Management Assertions By” field matches the name of the Organization that wrote the Management Assertions for the Standard Audit.
- All audit statement links point to PDF files, and are new links (so audit archiving will pick up the new audits).
- Audit statement PDF files are less than 25MB, so the audit archiving program will accept them.
- If an audit statement is not on the webtrust.org site or the auditor’s site, independently contact the auditor to confirm the authenticity of the audit statement.
- The dates all match the dates listed in the audit statements.
- The Audit Statement Date must be either the date of the audit statement or 90 days from the end of the audit period (whichever date is closest to the end of the audit period).
- The CP/CPS document(s) provide the necessary information for the corresponding root certificates, including appropriate validation procedures.
- The CP/CPS documents were updated some time in the last year.
- The CP/CPS Last Updated Date matches the dates in the CP/CPS document(s).
- All of the root certificates in the listed Root Cases are specifically
referenced in the audit statements.
- If a listed Root Case has “BR Audit” selected, then confirm that root certificate is specifically mentioned in the BR audit statement.
- If a listed Root Case has “EV Audit” selected, then confirm that root certificate is specifically mentioned in the EV audit statement.
- In each listed Root Case confirm that:
- The appropriate audits have been selected, corresponding to all of the Root Store Status (i.e.trust bits, EV Policy OID)
- The test websites have TLS/SSL certs chaining up to the corresponding root
certificate specified in the Root Case, and that they function as expected
(valid, expired, revoked):
- When you browse to ‘Test Website - Valid’, the connection is successful.
- When you browse to ‘Test Website - Revoked’ the revoked cert error is shown.
- When you browse to ‘Test Website - Expired’ the expired cert error is shown.
- For all three test websites, the certificate chains up to the relevant root certificate.
- If the EV SSL audit statement is selected for the root cert, then the TLS/SSL certs in the test websites must be EV; i.e. have the EV Policy OID(s).
When all of the information has been verified for the ‘Audit Case’ and corresponding Root Cases (“Request Status” is ‘Data Verified’ for all of them), a root store operator will click on a ‘Sync AuditUpdateInfo’ button that will propagate the audit, CP/CPS, and test website data to root certificate records corresponding to each of the Root Cases. The root store operator will be taken through a series of pages that look similar to the ‘Mass Update Audit/CP/CPS Data’ button on certificate records.
In the updated root certificate records, each time an audit statement link is changed, the corresponding audit archive status is changed to “Not Processed”. The next time the File Archive program is run, the audit statement will be imported and saved in the CCADB.