CA:CommonCADatabase: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Moved content to ccadb.org)
(Moved content to ccadb.org)
 
Line 4: Line 4:
<br />
<br />


= Request a license =
CA Community Licenses are granted to CAs in the root store programs of participating root store operators. '''You only need one CA Community License''' to access the CCADB data relating all participating root store programs.
If you believe that you should have a CCADB license but you have not received one, then please send email to support@ccadb.org with your name and the name of the CA you represent.
= Root Store Specific Instructions =
Root Store specific instructions for CAs in regards to the Common CA Database are here:
* [https://social.technet.microsoft.com/wiki/contents/articles/33315.microsoft-trusted-root-certificate-program-portal.aspx Specific instructions for CAs in Microsoft's CA Program]
* [[CA:SalesforceCommunity|Specific instructions for CAs in Mozilla's CA Program]]


= Getting Started =
= Getting Started =
After you receive email with your CA Community License, you may login to the Common CA Database as follows:
<br />
# Browse to: https://ccadb.force.com
The content of this section has been moved to http://ccadb.org/cas/getting-started
# Enter your Username; the email address for which your Community User License was issued
<br />
# Enter the Password that you set up during first access
# Click on the "Log In" button
 
Upon initial login you will see a row with five tabs:
# Home
# 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.
# Contacts
#* Click on "Contacts" tab, then in "View:" select "All Contacts" and click on "Go!". Click on the Name to view the contact record.
# CA Communications (Page)
#* This tab may be used when a root store operator polls their CA members for information.
#* You may ignore this tab, unless you receive email from a root store operator asking you to respond using this tab.
# 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 the CRM.)
* 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 the CRM.)
* CA Community Users cannot modify the records for: Owner, Root Certificate, and Contact. Only the Root Store Members can modify these records.
* CA Community Users can only modify the intermediate certificate records for their CA.
* When PEM data is provided, the certificate details in the record may not be modified.
 
= PEM Data =
[https://en.wikipedia.org/wiki/X.509#Certificate_filename_extensions PEM] data is used to enter root and intermediate certificate data into the CCADB. PEM is a container format defined in RFC's [https://tools.ietf.org/html/rfc1421 1421] through [https://tools.ietf.org/html/rfc1424 1424] that includes just the public certificate when used within the CCADB. PEM actually means Privacy Enhanced Mail, but the container format it used is a base64 translation of [https://en.wikipedia.org/wiki/X.509 X.509] [https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One ASN.1] keys.
<br /><br />
[https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's TLS Observatory Certificate Explainer] may be used to get the PEM format of a certificate.
* https://tls-observatory.services.mozilla.com/static/certsplainer.html
* In the 'Post a certificate' section click on the 'Browse...' button to select a .cer, .crt, .cert, or .pem file
* Check the top of the window to make sure there are no errors listed, and that the desired certificate has been found.
* The data in the text box in the 'Post a certificate' section is the PEM.
* Copy and past the entire PEM blob, which starts with "-----BEGIN CERTIFICATE-----" and ends with "-----END CERTIFICATE-----"


= Updating Audit Information =
= Updating Audit Information =
All Root Store Members require their CAs to provide updated statements annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties, as outlined in the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] and as outlined in each root store operator's policies.
== How To Provide Annual Updates ==
=== Overview ===
Records and Cases in the Common CA Database (CCADB) are organized in hierarchies, similar in concept to CA 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.
Cases are also designed in a hierarchical manner. 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.
* The audit statement links must change each year, so that the audit archiving will pick up the new version of the files.
* The audit statement links must point to pdf files that are smaller than 25MB.
* Links to updated CP/CPS documents. CP/CPS documents must be updated each year.
* 3 Test websites  (valid, expired, revoked) for each root certificate that has the TLS/SSL usage (trust bit) enabled. Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."
=== Instructions ===
Instructions for CAs to provide their annual updates via the Common CA Database (CCADB):
# [[CA:CommonCADatabase#Getting_Started|Login to the CCADB.]]
# There are two ways to create an Audit Case to provide your annual udpates.
#* 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.
# 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.
#* '''Important:''' The audit statement links must point to pdf files that are smaller than 25MB.
#* '''Important:''' The audit statement links must change each year, so that the audit archiving will pick up the new version of the files.
#* '''Important:''' Audit statements must be provided in English.
#* [[CA:SalesforceCommunity#Audit_Information|Explanation of Audit Information fields]]
#* [[CA:SalesforceCommunity#Policies_and_Practices_Information|Explanation of CP/CPS Information fields]]
# '''After you have provided the audit and CP/CPS information, you will need to tell us which root certificates are covered by these audits, as follows.'''
# 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.
# 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, revoked)
#** 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
#*** A revoked certificate can expire, at which point, it becomes an expired certificate. Including expired certs in CRLs is not a direct violation of RFC 5280 section 5 (since it doesn't say you cannot also list expired certificates), but the premise of RFC 5280 CRLs was that you SHOULD NOT do this.
#** Section 2.2 of the [https://cabforum.org/baseline-requirements-documents/ BRs]: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate.  At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."
#* 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.
Helpful Hints:
* 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 (i.e. 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 [[CA:CommonCADatabase:RootStoreOperators|root store operator]] will review and verify the information. Here's what they verify:
* The Auditor is an independent and qualified auditor, and that the provide "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 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 statements
* The dates all match the dates listed in the audit statements
* 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. Confirm that the CP/CPS documents are reasonably current.
* The CP/CPS Last Updated Date matches the dates in the CP/CPS document(s).
** According to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements], the CP/CPS must be updated annually.
* 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)
*** All three test websites are required as per the last paragraph in section 2.2 of Baseline Requirements.
*** Make sure that you can successfully browse to 'Test Website - Valid'.
*** Make sure that when you browse to 'Test Website - Revoked' you get the revoked cert error.
*** Make sure that when you browse to 'Test Website - Expired' you get the expired cert error.
*** For all three test websites, check the certificate chain to make sure they chain up to that 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.
<br />
<br />
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 [[CA:SalesforceCommunity#Audit_Archive|File Archive]] program is run, the audit statement will be imported and saved in the CCADB.
The content of this section has been moved to http://ccadb.org/cas/updates
<br />

Latest revision as of 22:49, 8 June 2017

Common CA Database (CCADB)


The content of this page has been moved to http://ccadb.org/


Getting Started


The content of this section has been moved to http://ccadb.org/cas/getting-started

Updating Audit Information


The content of this section has been moved to http://ccadb.org/cas/updates

Retrieved from "https://wiki.mozilla.org/index.php?title=CA:CommonCADatabase&oldid=1173030"