Confirmed users, Administrators
5,526
edits
CA/Audit Letter Validation: Difference between revisions
Jump to navigation
Jump to search
Clarified Acceptable Remediation section
m (added clarification) |
(Clarified Acceptable Remediation section) |
||
| Line 42: | Line 42: | ||
* Self-signed certificates that share a [https://tools.ietf.org/html/rfc5280#section-4.1.2.6 Subject] and [https://tools.ietf.org/html/rfc5280#section-4.1.2.7 SPKI] with a root certificate that is included in a root store are treated by browsers as intermediates because they chain up to an included root, so these certificates must also be listed in the applicable audit statements according to the "Derived Trust Bits" field. An example of this situation is when an older version of a root certificate exists but a newer version of the root certificate was created in order to be included in Mozilla's root store. In this case, a valid chain may be constructed as: leaf --> untrusted root --> trusted root. In other words, that "untrusted" root is technically trusted by Mozilla because it chains to a trusted root, so it's SHA256 fingerprint must also be listed in the applicable audit statements. | * Self-signed certificates that share a [https://tools.ietf.org/html/rfc5280#section-4.1.2.6 Subject] and [https://tools.ietf.org/html/rfc5280#section-4.1.2.7 SPKI] with a root certificate that is included in a root store are treated by browsers as intermediates because they chain up to an included root, so these certificates must also be listed in the applicable audit statements according to the "Derived Trust Bits" field. An example of this situation is when an older version of a root certificate exists but a newer version of the root certificate was created in order to be included in Mozilla's root store. In this case, a valid chain may be constructed as: leaf --> untrusted root --> trusted root. In other words, that "untrusted" root is technically trusted by Mozilla because it chains to a trusted root, so it's SHA256 fingerprint must also be listed in the applicable audit statements. | ||
'''Acceptable remediation''' | '''Acceptable remediation:''' <br /> | ||
* Have your auditor issue a revised report that includes the intermediate certificate. | Remediation may include one of the following when a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained non-technically-constrained] intermediate certificate is missing from an audit statement. Note that [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited Mozilla's Root Store Policy] says: "If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports." | ||
* Revoke the intermediate certificate in accordance with | * Have your auditor issue a revised report that includes the intermediate certificate. | ||
** This will '''not''' be an acceptable remediation if the certificate has been in existence for past audit periods. | |||
** This is an acceptable remediation when the certificate is self-signed and has the same Subject and SPKI as other certificates listed in the audit statement. For example, this can happen when Mozilla includes one version of a root certificate, but another version of the root certificate can be part of a valid chain constructed as: leaf --> untrusted root --> trusted root. | |||
* Revoke the intermediate certificate in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation Mozilla's Root Store Policy]. | |||
** If your CA decides not to revoke the certificate within the timeline specified by section 4.9 of the [https://cabforum.org/baseline-requirements-documents/ BRs], then that is another incident, which must be addressed in a [[CA/Responding_To_An_Incident#Incident_Report|separate Incident Report]]. | |||
* If the intermediate certificate is technically capable but not intended for TLS issuance, and revocation is not imminent, you may request that Mozilla add it to OneCRL by adding a comment to the Bugzilla bug with the request and [mailto:certificates@mozilla.org sending email to Mozilla]. Note: While adding the certificate to OneCRL satisfies Mozilla's expectations for remediation, it may not satisfy other root store programs. You are advised to seek their guidance on this issue. | * If the intermediate certificate is technically capable but not intended for TLS issuance, and revocation is not imminent, you may request that Mozilla add it to OneCRL by adding a comment to the Bugzilla bug with the request and [mailto:certificates@mozilla.org sending email to Mozilla]. Note: While adding the certificate to OneCRL satisfies Mozilla's expectations for remediation, it may not satisfy other root store programs. You are advised to seek their guidance on this issue. | ||
'''CA Task List''': A report is available via a Task List item on each CA's CCADB home page which identifies intermediate certificate records that have FAIL for either "Standard Audit ALV Found Cert" or "BR Audit ALV Found Cert". In the summary section of the CA Task List this item is called "Intermediate Certs with Failed ALV Results", and the corresponding report (available when the value is non-zero) is called "Check failed Audit Letter Validation (ALV) results". | '''CA Task List''': A report is available via a Task List item on each CA's CCADB home page which identifies intermediate certificate records that have FAIL for either "Standard Audit ALV Found Cert" or "BR Audit ALV Found Cert". In the summary section of the CA Task List this item is called "Intermediate Certs with Failed ALV Results", and the corresponding report (available when the value is non-zero) is called "Check failed Audit Letter Validation (ALV) results". | ||