136
edits
Changes
Move Precertificates to recommended
* Ensure Intrusion Detection System and other monitoring software is up-to-date.
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.
== Recommended Practices ==
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.
=== Precertificates ===
The current implementation of [https://www.certificate-transparency.org/ Certificate Transparency] does not provide any way for Relying Parties to determine if a certificate corresponding to a given precertificate has or has not been issued. It is only safe to assume that a certificate corresponding to every precertificate exists.
[https://tools.ietf.org/html/rfc6962 RFC 6962] states “The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate).”
However, [https://cabforum.org/baseline-requirements-documents/ BR] section 7.1.2.5 states “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.”
Mozilla [https://cabforum.org/pipermail/public/2014-January/002694.html interprets] the BR language as a specific exception allowing CAs to issue a precertificate containing the same serial number as the subsequent certificate. Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued.
This means, for example, that:
* A CA must provide OCSP services and responses in accordance with Mozilla policy for all certificates presumed to exist based on the presence of a Precertificate, even if the certificate does not actually exist
* A CA must be able to revoke a certificate presumed to exist, if revocation of the certificate is required under Mozilla policy, even if the certificate does not actually exist.
* If any corresponding certificate with the same serial number and issuer exists, and can not be verified to match the precertificate using the algorithms in RFC 6962, it will be considered misissued.
* In examining historical issuance, the CA must consider both final certificates and precertificates, even if the precertificate did not ultimately result in the issuance of a certificate.
