CA:TestErrors
From MozillaWiki
Test Errors
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.
Error | Meaning | Recommended Resolution | Related Bug |
---|---|---|---|
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 | bug 1040072 |
Error while parsing CRL | 403 Forbidden when trying to download the CRL files | bug 1233645#c13 | |
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 | bug 1233645#c13 |
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. | bug 944783#c51 |
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. | bug 1099311#c14 |
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. | bug 1099311#c14 |
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
Error | Meaning | Recommended Resolution | Related Bug |
---|---|---|---|
Generalized Time before 2050 | certs aren't conforming to section 4.1.2.5 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. | bug 999378#c30 |
CA certificates must include commonName in subject | not strictly against the Baseline Requirements | should be a Warning message | 435736#c159 |
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. | 1201423#c20 |
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. | bug 636557#c56 |
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 7.1.4.2 of the Baseline Requirements only applies to end-entity certs | Discussion in mozilla.dev.security.policy concluded that section 7.1.4.2 of the BRs only applies to end-entity certs. So we can ignore these errors for root and intermediate certificates. | bug 1099311#c19 |