CA:TestErrors

From MozillaWiki
Jump to: navigation, search

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

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. Browse to https://crt.sh/
  2. Enter the SHA-1 or SHA-256 Fingerprint for the root certificate. Then click on the 'Search' button.
  3. 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.
  4. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Alternatively, you may use the test code directly via Github:

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
Retrieved from "https://wiki.mozilla.org/index.php?title=CA:TestErrors&oldid=1166347"