OPENSSL-VERIFICATION-OPTIONS(1SSL) OpenSSL OPENSSL-VERIFICATION-OPTIONS(1SSL)
NAME
openssl-verification-options - generic X.509 certificate verification
options
SYNOPSIS
openssl command [ options ... ] [ parameters ... ]
DESCRIPTION
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).
Trust Anchors
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:
• It is an an element of the trust store.
• It does not have a negative trust attribute rejecting the given use.
• It has a positive trust attribute accepting the given use or (by
default) one of the following compatibility conditions apply: It is
self-signed or the -partial_chain option is given (which corresponds
to the X509_V_FLAG_PARTIAL_CHAIN flag being set).
Certification Path Building
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:
• Its subject name matches the issuer name of the subject certificate.
• If the subject certificate has an authority key identifier
extension, each of its sub-fields equals the corresponding subject
key identifier, serial number, and issuer field of the candidate
issuer certificate, as far as the respective fields are present in
both certificates.
• The certificate signature algorithm used to sign the subject
certificate is supported and equals the public key algorithm of the
candidate issuer certificate.
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.
Certification Path Validation
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.
OPTIONS
Trusted Certificate Options
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.
-CAfile file
Load the specified file which contains a trusted certificate in DER
format or potentially several of them in case the input is in PEM
format. PEM-encoded certificates may also have trust attributes
set.
-no-CAfile
Do not load the default file of trusted certificates.
-CApath dir
Use the specified directory as a collection of trusted certificates,
i.e., a trust store. Files should be named with the hash value of
the X.509 SubjectName of each certificate. This is so that the
library can extract the IssuerName, hash it, and directly lookup the
file to get the issuer certificate. See openssl-rehash(1) for
information on creating this type of directory.
-no-CApath
Do not use the default directory of trusted certificates.
-CAstore uri
Use uri as a store of CA certificates. The URI may indicate a
single certificate, as well as a collection of them. With URIs in
the "file:" scheme, this acts as -CAfile or -CApath, depending on if
the URI indicates a single file or directory. See
ossl_store-file(7) for more information on the "file:" scheme.
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)).
-no-CAstore
Do not use the default store of trusted CA certificates.
Verification Options
The certificate verification can be fine-tuned with the following flags.
-verbose
Print extra information about the operations being performed.
-attime timestamp
Perform validation checks using time specified by timestamp and not
current system time. timestamp is the number of seconds since
January 1, 1970 (i.e., the Unix Epoch).
-no_check_time
This option suppresses checking the validity period of certificates
and CRLs against the current time. If option -attime is used to
specify a verification time, the check is not suppressed.
-x509_strict
This disables non-compliant workarounds for broken certificates.
Thus errors are thrown on certificates not compliant with RFC 5280.
When this option is set, among others, the following certificate
well-formedness conditions are checked:
• The basicConstraints of CA certificates must be marked critical.
• CA certificates must explicitly include the keyUsage extension.
• If a pathlenConstraint is given the key usage keyCertSign must
be allowed.
• The pathlenConstraint must not be given for non-CA certificates.
• The issuer name of any certificate must not be empty.
• The subject name of CA certs, certs with keyUsage crlSign, and
certs without subjectAlternativeName must not be empty.
• If a subjectAlternativeName extension is given it must not be
empty.
• The signatureAlgorithm field and the cert signature must be
consistent.
• Any given authorityKeyIdentifier and any given
subjectKeyIdentifier must not be marked critical.
• The authorityKeyIdentifier must be given for X.509v3 certs
unless they are self-signed.
• The subjectKeyIdentifier must be given for all X.509v3 CA certs.
-ignore_critical
Normally if an unhandled critical extension is present that is not
supported by OpenSSL the certificate is rejected (as required by
RFC5280). If this option is set critical extensions are ignored.
-issuer_checks
Ignored.
-crl_check
Checks end entity certificate validity by attempting to look up a
valid CRL. If a valid CRL cannot be found an error occurs.
-crl_check_all
Checks the validity of all certificates in the chain by attempting
to look up valid CRLs.
-use_deltas
Enable support for delta CRLs.
-extended_crl
Enable extended CRL features such as indirect CRLs and alternate CRL
signing keys.
-suiteB_128_only, -suiteB_128, -suiteB_192
Enable the Suite B mode operation at 128 bit Level of Security, 128
bit or 192 bit, or only 192 bit Level of Security respectively. See
RFC6460 for details. In particular the supported signature
algorithms are reduced to support only ECDSA and SHA256 or SHA384
and only the elliptic curves P-256 and P-384.
-auth_level level
Set the certificate chain authentication security level to level.
The authentication security level determines the acceptable
signature and public key strength when verifying certificate chains.
For a certificate chain to validate, the public keys of all the
certificates must meet the specified security level. The signature
algorithm security level is enforced for all the certificates in the
chain except for the chain's trust anchor, which is either directly
trusted or validated by means other than its signature. See
SSL_CTX_set_security_level(3) for the definitions of the available
levels. The default security level is -1, or "not set". At
security level 0 or lower all algorithms are acceptable. Security
level 1 requires at least 80-bit-equivalent security and is broadly
interoperable, though it will, for example, reject MD5 signatures or
RSA keys shorter than 1024 bits.
-partial_chain
Allow verification to succeed if an incomplete chain can be built.
That is, a chain ending in a certificate that normally would not be
trusted (because it has no matching positive trust attributes and is
not self-signed) but is an element of the trust store. This
certificate may be self-issued or belong to an intermediate CA.
-check_ss_sig
Verify the signature of the last certificate in a chain if the
certificate is supposedly self-signed. This is prohibited and will
result in an error if it is a non-conforming CA certificate with key
usage restrictions not including the keyCertSign bit. This
verification is disabled by default because it doesn't add any
security.
-allow_proxy_certs
Allow the verification of proxy certificates.
-trusted_first
As of OpenSSL 1.1.0 this option is on by default and cannot be
disabled.
When constructing the certificate chain, the trusted certificates
specified via -CAfile, -CApath, -CAstore or -trusted are always used
before any certificates specified via -untrusted.
-no_alt_chains
As of OpenSSL 1.1.0, since -trusted_first always on, this option has
no effect.
-trusted file
Parse file as a set of one or more certificates. Each of them
qualifies as trusted if has a suitable positive trust attribute or
it is self-signed or the -partial_chain option is specified. This
option implies the -no-CAfile, -no-CApath, and -no-CAstore options
and it cannot be used with the -CAfile, -CApath or -CAstore options,
so only certificates specified using the -trusted option are trust
anchors. This option may be used multiple times.
-untrusted file
Parse file as a set of one or more certificates. All certificates
(typically of intermediate CAs) are considered untrusted and may be
used to construct a certificate chain from the target certificate to
a trust anchor. This option may be used multiple times.
-policy arg
Enable policy processing and add arg to the user-initial-policy-set
(see RFC5280). The policy arg can be an object name or an OID in
numeric form. This argument can appear more than once.
-explicit_policy
Set policy variable require-explicit-policy (see RFC5280).
-policy_check
Enables certificate policy processing.
-policy_print
Print out diagnostics related to policy processing.
-inhibit_any
Set policy variable inhibit-any-policy (see RFC5280).
-inhibit_map
Set policy variable inhibit-policy-mapping (see RFC5280).
-purpose purpose
A high-level specification of the intended use of the target
certificate. Currently predefined purposes are "sslclient",
"sslserver", "nssslserver", "smimesign", "smimeencrypt", "crlsign",
"ocsphelper", "timestampsign", "codesign" and "any". If peer
certificate verification is enabled, by default the TLS
implementation and thus the commands openssl-s_client(1) and
openssl-s_server(1) check for consistency with TLS server
("sslserver") or TLS client use ("sslclient"), respectively. By
default, CMS signature validation, which can be done via
openssl-cms(1), checks for consistency with S/MIME signing use
("smimesign").
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.
-verify_depth num
Limit the certificate chain to num intermediate CA certificates. A
maximal depth chain can have up to num+2 certificates, since neither
the end-entity certificate nor the trust-anchor certificate count
against the -verify_depth limit.
-verify_email email
Verify if email matches the email address in Subject Alternative
Name or the email in the subject Distinguished Name.
-verify_hostname hostname
Verify if hostname matches DNS name in Subject Alternative Name or
Common Name in the subject certificate.
-verify_ip ip
Verify if ip matches the IP address in Subject Alternative Name of
the subject certificate.
-verify_name name
Use a set of verification parameters, also known as verification
method, identified by name. The currently predefined methods are
named "ssl_client", "ssl_server", "smime_sign" with alias "pkcs7",
"code_sign", and "default". These mimic the combinations of purpose
and trust settings used in SSL/(D)TLS, CMS/PKCS7 (including S/MIME),
and code signing.
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).
Extended Verification Options
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.
-xkey infile, -xcert infile, -xchain
Specify an extra certificate, private key and certificate chain.
These behave in the same manner as the -cert, -key and -cert_chain
options. When specified, the callback returning the first valid
chain will be in use by the client.
-xchain_build
Specify whether the application should build the certificate chain
to be provided to the server for the extra certificates via the
-xkey, -xcert, and -xchain options.
-xcertform DER|PEM|P12
The input format for the extra certificate. This option has no
effect and is retained for backward compatibility only.
-xkeyform DER|PEM|P12
The input format for the extra key. This option has no effect and
is retained for backward compatibility only.
Certificate Extensions
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.
(D)TLS Client ("sslclient")
Any given extended key usage extension must allow for "clientAuth"
("TLS WWW client authentication").
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.
(D)TLS Server ("sslserver")
Any given extended key usage extension must allow for "serverAuth"
("TLS WWW server authentication") and/or include one of the SGC
OIDs.
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.
Netscape SSL Server ("nssslserver")
In addition to what has been described for sslserver, for a Netscape
SSL client to connect to an SSL server, its EE certficate must have
the keyEncipherment bit set if the keyUsage extension is present.
This isn't always valid because some cipher suites use the key for
digital signing. Otherwise it is the same as a normal SSL server.
Common S/MIME Checks
Any given extended key usage extension must allow for
"emailProtection".
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.
S/MIME Signing ("smimesign")
In addition to the common S/MIME checks, for target certficiates the
key usage must allow for "digitalSignature" and/or nonRepudiation.
S/MIME Encryption ("smimeencrypt")
In addition to the common S/MIME checks, for target certficiates the
key usage must allow for "keyEncipherment".
CRL Signing ("crlsign")
For target certificates, the key usage must allow for "cRLSign".
For all other certifcates the normal CA checks apply. Except in
this case the basicConstraints extension must be present.
OCSP Helper ("ocsphelper")
For target certificates, no checks are performed at this stage, but
special checks apply; see OCSP_basic_verify(3).
For all other certifcates the normal CA checks apply.
Timestamp Signing ("timestampsign")
For target certificates, if the key usage extension is present, it
must include "digitalSignature" and/or "nonRepudiation" and must not
include other bits. The EKU extension must be present and contain
"timeStamping" only. Moreover, it must be marked as critical.
For all other certifcates the normal CA checks apply.
Code Signing ("codesign")
For target certificates, the key usage extension must be present and
marked critical and include <digitalSignature>, but must not include
"keyCertSign" nor "cRLSign". The EKU extension must be present and
contain "codeSign", but must not include "anyExtendedKeyUsage" nor
"serverAuth".
For all other certifcates the normal CA checks apply.
BUGS
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.
SEE ALSO
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)
HISTORY
The checks enabled by -x509_strict have been extended in OpenSSL 3.0.
COPYRIGHT
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>.
3.5.4 2025-09-30OPENSSL-VERIFICATION-OPTIONS(1SSL)
Generated by dwww version 1.16 on Tue Dec 16 04:06:55 CET 2025.