Phasing Out SHA-1 Certificates

As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL and S/MIME certificates, as well as any intermediate certificates that they chain up to. CAs have been asked to check their systems and those of their subordinate CAs to ensure that SHA-1 based TLS/SSL and S/MIME certificates chaining up to their included root certificates are no longer being issued, and that any such certificates issued after 2016-01-01 have been revoked.

Additionally, it has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1.

Legacy Systems Do Not Support SHA-1

Unfortunately, some CA customers have not yet been able to migrate all of their systems to support SHA-256 as a certificate signature algorithm, so many customers still depend on SHA-1 certificates.

For such situations, the following minimum requirements must be met:

1. CAs must separate their SHA-1 certificate issuance from anything that can issue certificates for the web, using technical constraints in the intermediate issuing certificates.
   • To continue issuing SHA-1 certificates, the CA must use a separate intermediate certificate that has the Extended Key Usage (EKU) extension with the appropriate KeyPurposeId, and the EKU extension must not include KeyPurposeId id-kp-serverAuth and must not include KeyPurposeId anyExtendedKeyUsage.
   • There are some root certificates included in Mozilla's CA Certificate Program that only have the Email trust bit enabled; i.e. they do not have the Websites trust bit enabled. Issuing certificates chaining up to such root certificates are already considered technically constrained.
2. SHA-1 certificates may only be issued by a technically constrained SHA-1 SubCA that chains to an old SHA-1 (or older) root certificate. Such subCA must have as many technical constraints in the subCA's certificate validity as possible, including restrictions in key usage, extended key usage, subCA validity period and distinguished name ("path name restrictions").
3. SHA-1 certificates must include CA generated random values that are not known by the 3rd party prior to issuance (and thus prior to request generation). Any such random values must contain the same number of bits as the signing hash (e.g. 20 bytes/160 bits for SHA-1 signed certificates). Any such random values must occur before most (preferably all) 3rd party supplied fields to protect against prefix collision based attacks.
   • In practice, placing the first 160 random bits in the certificate serial number, adding the next 12 random bits to the "NotBefore time" as a count of seconds, the next 12 random bits to the "NotAfter time" as a count of seconds and inserting any remaining bits as an early element in the subject distinguished name would be the closest allowed by X.509v3 and older.
   • OCSP responses for actually issued certificates should be pre-generated independent of incoming OCSP requests and include the random values as close to the beginning of the response as technically possible. Dynamically generated OCSP responses (for multiple certicates, never-issued certificates etc.) should include a random value before any request-supplied values totaling more than half the number of bits in the signing hash.
4. SHA-1 certificates must be issued in a very minimal count, with short validity periods (1 to 16 months), and only to serve a specific purpose.
   • For example for CRL signing or OCSP signing where a documented technical reason must be given for not making such signatures using dedicated certificates (for example, a specific named client implementation might fail to accept OCSP responses and/or CRL signatures not signed directly by the CA).
   • As an example of reducing the frequency of such signatures, CRLs might be issued with longer than usual refresh intervals for older CAs that have few remaining valid certificates and are mostly reissuing CRLs to provide trusted lists of historic revocation dates.
5. All procedures performed to comply with the above rules must be documented in the relevant CP/CPS and verified by the annual audit.