OPENSSL-VERIFICATION-OPTIONS(1) | OpenSSL | OPENSSL-VERIFICATION-OPTIONS(1) |
openssl-verification-options - generic X.509 certificate verification options
openssl command [ options ... ] [ parameters ... ]
There are many situations where X.509 certificates are verified within the OpenSSL libraries and in various OpenSSL commands.
Certificate verification is implemented by X509_verify_cert(3). It is a complicated process consisting of a number of steps and depending on numerous options. The most important of them are detailed in the following sections.
In a nutshell, a valid chain of certificates needs to be built up and verified starting from the target certificate that is to be verified and ending in a certificate that due to some policy is trusted. Certificate validation can be performed in the context of a purpose, which is a high-level specification of the intended use of the target certificate, such as "sslserver" for TLS servers, or (by default) for any purpose.
The details of how each OpenSSL command handles errors are documented on the specific command page.
DANE support is documented in openssl-s_client(1), SSL_CTX_dane_enable(3), SSL_set1_host(3), X509_VERIFY_PARAM_set_flags(3), and X509_check_host(3).
In general, according to RFC 4158 and RFC 5280, a trust anchor is any public key and related subject distinguished name (DN) that for some reason is considered trusted and thus is acceptable as the root of a chain of certificates.
In practice, trust anchors are given in the form of certificates, where their essential fields are the public key and the subject DN. In addition to the requirements in RFC 5280, OpenSSL checks the validity period of such certificates and makes use of some further fields. In particular, the subject key identifier extension, if present, is used for matching trust anchors during chain building.
In the most simple and common case, trust anchors are by default all self-signed "root" CA certificates that are placed in the trust store, which is a collection of certificates that are trusted for certain uses. This is akin to what is used in the trust stores of Mozilla Firefox, or Apple's and Microsoft's certificate stores, ...
From the OpenSSL perspective, a trust anchor is a certificate that should be augmented with an explicit designation for which uses of a target certificate the certificate may serve as a trust anchor. In PEM encoding, this is indicated by the "TRUSTED CERTIFICATE" string. Such a designation provides a set of positive trust attributes explicitly stating trust for the listed purposes and/or a set of negative trust attributes explicitly rejecting the use for the listed purposes. The purposes are encoded using the values defined for the extended key usages (EKUs) that may be given in X.509 extensions of end-entity certificates. See also the "Extended Key Usage" section below.
The currently recognized uses are clientAuth (SSL client use), serverAuth (SSL server use), emailProtection (S/MIME email use), codeSigning (object signer use), OCSPSigning (OCSP responder use), OCSP (OCSP request use), timeStamping (TSA server use), and anyExtendedKeyUsage. As of OpenSSL 1.1.0, the last of these blocks all uses when rejected or enables all uses when trusted.
A certificate, which may be CA certificate or an end-entity certificate, is considered a trust anchor for the given use if and only if all the following conditions hold:
First, a certificate chain is built up starting from the target certificate and ending in a trust anchor.
The chain is built up iteratively, looking up in turn a certificate with suitable key usage that matches as an issuer of the current "subject" certificate as described below. If there is such a certificate, the first one found that is currently valid is taken, otherwise the one that expired most recently of all such certificates. For efficiency, no backtracking is performed, thus any further candidate issuer certificates that would match equally are ignored.
When a self-signed certificate has been added, chain construction stops. In this case it must fully match a trust anchor, otherwise chain building fails.
A candidate issuer certificate matches a subject certificate if all of the following conditions hold:
The lookup first searches for issuer certificates in the trust store. If it does not find a match there it consults the list of untrusted ("intermediate" CA) certificates, if provided.
When the certificate chain building process was successful the chain components and their links are checked thoroughly.
The first step is to check that each certificate is well-formed. Part of these checks are enabled only if the -x509_strict option is given.
The second step is to check the X.509v3 extensions of every certificate for consistency with the intended specific purpose, if any. If the -purpose option is not given then no such checks are done except for CMS signature checking, where by default "smimesign" is checked, and SSL/(D)TLS connection setup, where by default "sslserver" or "sslclient" are checked. The X.509v3 extensions of the target or "leaf" certificate must be compatible with the specified purpose. All other certificates down the chain are checked to be valid CA certificates, and possibly also further non-standard checks are performed. The precise extensions required are described in detail in the "Certificate Extensions" section below.
The third step is to check the trust settings on the last certificate (which typically is a self-signed root CA certificate). It must be trusted for the given use. For compatibility with previous versions of OpenSSL, a self-signed certificate with no trust attributes is considered to be valid for all uses.
The fourth, and final, step is to check the validity of the certificate chain. For each element in the chain, including the root CA certificate, the validity period as specified by the "notBefore" and "notAfter" fields is checked against the current system time. The -attime flag may be used to use a reference time other than "now." The certificate signature is checked as well (except for the signature of the typically self-signed root CA certificate, which is verified only if the -check_ss_sig option is given). When verifying a certificate signature the keyUsage extension (if present) of the candidate issuer certificate is checked to permit digitalSignature for signing proxy certificates or to permit keyCertSign for signing other certificates, respectively. If all operations complete successfully then certificate is considered valid. If any operation fails then the certificate is not valid.
The following options specify how to supply the certificates that can be used as trust anchors for certain uses. As mentioned, a collection of such certificates is called a trust store.
Note that OpenSSL does not provide a default set of trust anchors. Many Linux distributions include a system default and configure OpenSSL to point to that. Mozilla maintains an influential trust store that can be found at <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/>.
The certificates to add to the trust store can be specified using following options.
These certificates are also used when building the server certificate chain (for example with openssl-s_server(1)) or client certificate chain (for example with openssl-s_time(1)).
The certificate verification can be fine-tuned with the following flags.
When this option is set, among others, the following certificate well-formedness conditions are checked:
When constructing the certificate chain, the trusted certificates specified via -CAfile, -CApath, -CAstore or -trusted are always used before any certificates specified via -untrusted.
While IETF RFC 5280 says that id-kp-serverAuth and id-kp-clientAuth are only for WWW use, in practice they are used for all kinds of TLS clients and servers, and this is what OpenSSL assumes as well.
The verification parameters include the trust model, various flags that can partly be set also via other command-line options, and the verification purpose, which in turn implies certificate key usage and extended key usage requirements.
The trust model determines which auxiliary trust or reject OIDs are applicable to verifying the given certificate chain. They can be given using the -addtrust and -addreject options for openssl-x509(1).
Sometimes there may be more than one certificate chain leading to an end-entity certificate. This usually happens when a root or intermediate CA signs a certificate for another a CA in other organization. Another reason is when a CA might have intermediates that use two different signature formats, such as a SHA-1 and a SHA-256 digest.
The following options can be used to provide data that will allow the OpenSSL command to generate an alternative chain.
Options like -purpose and -verify_name trigger the processing of specific certificate extensions, which determine what certificates can be used for.
Basic Constraints
The basicConstraints extension CA flag is used to determine whether the certificate can be used as a CA. If the CA flag is true then it is a CA, if the CA flag is false then it is not a CA. All CAs should have the CA flag set to true.
If the basicConstraints extension is absent, which includes the case that it is an X.509v1 certificate, then the certificate is considered to be a "possible CA" and other extensions are checked according to the intended use of the certificate. The treatment of certificates without basicConstraints as a CA is presently supported, but this could change in the future.
Key Usage
If the keyUsage extension is present then additional restraints are made on the uses of the certificate. A CA certificate must have the keyCertSign bit set if the keyUsage extension is present.
Extended Key Usage
The extKeyUsage (EKU) extension places additional restrictions on certificate use. If this extension is present (whether critical or not) in an end-entity certficiate, the key is allowed only for the uses specified, while the special EKU anyExtendedKeyUsage allows for all uses.
Note that according to RFC 5280 section 4.2.1.12, the Extended Key Usage extension will appear only in end-entity certificates, and consequently the standard certification path validation described in its section 6 does not include EKU checks for CA certificates. The CA/Browser Forum requires for TLS server, S/MIME, and code signing use the presence of respective EKUs in subordinate CA certificates (while excluding them for root CA certificates), while taking over from RFC 5280 the certificate validity concept and certificate path validation.
For historic reasons, OpenSSL has its own way of interpreting and checking EKU extensions on CA certificates, which may change in the future. It does not require the presence of EKU extensions in CA certificates, but in case the verification purpose is "sslclient", "nssslserver", "sslserver", "smimesign", or "smimeencrypt", it checks that any present EKU extension (that does not contain anyExtendedKeyUsage) contains the respective EKU as detailed below. Moreover, it does these checks even for trust anchor certificates.
Checks Implied by Specific Predefined Policies
A specific description of each check is given below. The comments about basicConstraints and keyUsage and X.509v1 certificates above apply to all CA certificates.
For target certificates, the key usage must allow for "digitalSignature" and/or "keyAgreement". The Netscape certificate type must be absent or have the SSL client bit set.
For all other certificates the normal CA checks apply. In addition, the Netscape certificate type must be absent or have the SSL CA bit set. This is used as a workaround if the basicConstraints extension is absent.
For target certificates, the key usage must allow for "digitalSignature", "keyEncipherment", and/or "keyAgreement". The Netscape certificate type must be absent or have the SSL server bit set.
For all other certificates the normal CA checks apply. In addition, the Netscape certificate type must be absent or have the SSL CA bit set. This is used as a workaround if the basicConstraints extension is absent.
For target certificates, the Netscape certificate type must be absent or should have the S/MIME bit set. If the S/MIME bit is not set in the Netscape certificate type then the SSL client bit is tolerated as an alternative but a warning is shown. This is because some Verisign certificates don't set the S/MIME bit.
For all other certificates the normal CA checks apply. In addition, the Netscape certificate type must be absent or have the S/MIME CA bit set. This is used as a workaround if the basicConstraints extension is absent.
For all other certifcates the normal CA checks apply. Except in this case the basicConstraints extension must be present.
For all other certifcates the normal CA checks apply.
For all other certifcates the normal CA checks apply.
The issuer checks still suffer from limitations in the underlying X509_LOOKUP API. One consequence of this is that trusted certificates with matching subject name must appear in a file (as specified by the -CAfile option), a directory (as specified by -CApath), or a store (as specified by -CAstore). If there are multiple such matches, possibly in multiple locations, only the first one (in the mentioned order of locations) is recognised.
X509_verify_cert(3), OCSP_basic_verify(3), openssl-verify(1), openssl-ocsp(1), openssl-ts(1), openssl-s_client(1), openssl-s_server(1), openssl-smime(1), openssl-cmp(1), openssl-cms(1)
The checks enabled by -x509_strict have been extended in OpenSSL 3.0.
Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
2025-02-11 | 3.0.16 |