This page lists errors that CAs run into while doing the testing required for root inclusion/change requests, the meaning of those errors, and recommended resolution. Please add to this wiki page as you run into test errors that are not listed.
- Revocation Testing Errors -- Table of errors found by http://certificate.revocationcheck.com/
- CA/Browser Forum Baseline Requirements Errors -- Table of errors found by certlint or X509lint. Links to these tests are available via https://crt.sh/
Revocation Testing Errors
Revocation Test: Browse to http://certificate.revocationcheck.com/ and enter the Test Website URL. Make sure there are no errors listed in the output.
- Hint: Click on the "Raw data" button in the top right corner of the revocationcheck site to see the raw data that the site is checking.
|NextUpdate not set (RFC 5019, section 2.2.4)
|According to rfc6960 the nextUpdate value is optional, but according to rfc5019 (OCSP Profile for High-Volume Environments) it's required.
|The revocationcheck site is tuned CA's for high volume environments, so this may not be an issue for some CAs
|Error while parsing CRL
|403 Forbidden when trying to download the CRL files
|Error parsing OCSP response
|The OCSP signing certificate "ocsp.certification.tn" is used to sign the response for both end-entity and the CA certificate.
|The signing certificate needs to be delegated by the issuer of the certificate (ca-delegated) or the response needs to be signed by the issuer them self (ca-signed). See also: https://tools.ietf.org/html/rfc6960#section-2.6
|OCSP Response Is Not Yet Valid
|The validity is calculated based on the date header in the http response (when present).
|As the header is available (as in most cases) this is likely a time synchronisation issue on a webserver, reversed proxy or CDN. Each http server in the chain will update the date header, if you have multiple servers for caching and load balancing they will set this date.
|We could not identify the issuer for this certificate
|there is missing an intermediate or the system doesn't have the root certificate.
|https://certificate.revocationcheck.com/ -> Certificate Upload -> Upload the root cert to that server (e.g. add PEM for the root cert) -> Check Revocation Status. Then go back to https://certificate.revocationcheck.com/ and enter the OCSP url. Note: The issuer certificate may not be needed, but if it is, it can contain multiple certs to complete the chain back to the root.
|The Cache-Control max-age header outlives NextUpdate with ...
|The cache instructions in the cache-control header exceed the validity of the response. Say that a repose is still valid for 9.5 hours, but it’s instructed to cache for 10 hours, users will get an expired (cached) response for an half hour.
|The value is often set by the origin while the request is served by a CDN who is not recalculating the value based on the expires value of the response. This also depends on the CDN cache times. Often it’s easier to remove the max-age value from the cache control header and rely on the expires and last-modified headers for caching.
CA/Browser Forum Baseline Requirements Errors
CAs MUST check that they are not issuing certificates that violate any of the CA/Browser Forum Baseline Requirements (BRs).
Mozilla WILL check that the CA is not issuing certificates that violate any of the BRs by performing the following tests.
- Browse to https://crt.sh/
- Enter the SHA-1 or SHA-256 Fingerprint for the root certificate. Then click on the 'Search' button.
- When the certificate information is shown, along the left column under Certificate, click on the "Run cablint" and "Run x509lint" links. Each of these will add a row to the table, showing the test results.
- All errors must be resolved/fixed. Warnings should also be either resolved or explained.
Alternatively, you may use the test code directly via Github:
- BR Lint Test: https://github.com/awslabs/certlint
- X.509 Lint Test: https://github.com/kroeckx/x509lint
|Generalized Time before 2050
|certs aren't conforming to section 18.104.22.168 of rfc 5280 regarding when to use UTCTime and when to use GeneralizedTime.
|Any dates before 2050 must be encoded as UTCTime. It doesn't look like mozilla::pkix enforces this, though. We might think about eventually doing so.
|CA certificates must include commonName in subject
|not strictly against the Baseline Requirements
|should be a Warning message
|Unallowed key usage for EC public key
|"keyEncipherment" is not allowed for EC keys
|Section 3 of RFC 5480 (https://tools.ietf.org/html/rfc5480#section-3) defines the keyUsage bits allowed with Elliptic Curve Cryptography Subject Public Key Information. keyEncipherment is not on the list.
|Unallowed key usage for RSA public key
|https://tools.ietf.org/html/rfc5280 page 30. A certificate with an RSA key should not assert keyAgreement.
|A certificate that has an RSA key and asserts the keyAgreement usage is technically a non-conforming certificate. We are not aware of any implementation that would actually have a problem verifying that certificate, but we think that CAs should not be issuing certificates with this problem.
|CA certificates must set keyUsage extension as critical
|The Baseline Requirements say that the keyUsage extension MUST be present and MUST be marked critical.
|This requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. In general, CAs should not be requesting inclusion of CA certs created before that date.
|Subject with organizationName but without stateOrProvince or localityName, include countryName in subject
|Section 22.214.171.124 of the Baseline Requirements only applies to end-entity certs
|Discussion in mozilla.dev.security.policy concluded that section 126.96.36.199 of the BRs only applies to end-entity certs. So we can ignore these errors for root and intermediate certificates.