CA:TestErrors: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (comment number)
m (Added info about RSA keys and key Agreement)
Line 45: Line 45:
| 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. || {{Bug||1201423#c20}}
| 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. || {{Bug||1201423#c20}}
|-
|-
| Unallowed key usage for RSA public key  || https://tools.ietf.org/html/rfc5280 page 30 || ??? || {{Bug|636557#c52}}
| 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}}
|-
|-
|  ||  || ||
|  ||  || ||

Revision as of 17:21, 10 October 2016

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. 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