CA:TestErrors: Difference between revisions
Jump to navigation
Jump to search
(Created page) |
m (country name) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
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. | 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. | ||
* [[CA:TestErrors#Revocation_Testing_Errors|Revocation Testing Errors]] -- Table of errors found by http://certificate.revocationcheck.com/ | |||
* [[CA:TestErrors#CA.2FBrowser_Forum_Baseline_Requirements_Errors|CA/Browser Forum Baseline Requirements Errors]] -- Table of errors found by [https://github.com/awslabs/certlint certlint] or [https://github.com/kroeckx/x509lint X509lint]. Links to these tests are available via https://crt.sh/ | |||
== Revocation Testing Errors == | == 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. | Revocation Test: Browse to http://certificate.revocationcheck.com/ and enter the Test Website URL. Make sure there are no errors listed in the output. | ||
== CA/Browser Forum Baseline | * 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. | ||
CAs MUST check that they are not issuing certificates that violate any of the [https://cabforum.org/baseline-requirements/ 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. | |||
# | {| class="wikitable" | ||
|- | |||
! 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 [https://cabforum.org/baseline-requirements/ CA/Browser Forum Baseline Requirements] (BRs). | |||
<br /> <br /> | |||
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 | |||
{| class="wikitable" | |||
|- | |||
! 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 || {{Bug||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. || {{Bug||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 [https://cabforum.org/baseline-requirements-documents/ 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 [https://cabforum.org/baseline-requirements-documents/ Baseline Requirements] only applies to end-entity certs || [https://groups.google.com/d/msg/mozilla.dev.security.policy/yV84X0xkkEo/cPyt4G7YCQAJ 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}} | |||
|- | |||
| || || || | |||
|} | |||
Latest revision as of 23:29, 21 March 2017
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 |