CA:TestErrors

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 https://cert-checker.allizom.org/ or 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.

1. CA/Browser Forum Compliance: Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.
2. Cert chain of test website: Browse to https://cert-checker.allizom.org/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

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.