doc/man1/openssl-verification-options.pod

=pod

=head1 NAME

openssl-verification-options - generic X.509 certificate verification options

=head1 SYNOPSIS

B<openssl>
I<command>
[ I<options> ... ]
[ I<parameters> ... ]

=head1 DESCRIPTION

There are many situations where X.509 public-key certificates are verified
within the OpenSSL libraries and in various OpenSSL commands.
For checking certificates, the term I<validation> would actually be more
appropriate,
but for historical reasons the term I<verification> is often used instead.

In the sequel, the certificate to be validated is called I<target certificate>.
Since it usually is an end-entity (EE) certificate, it is also known as
"leaf" certificate (of a chain or tree), but it may also be a CA certificate.
Certificate verification is implemented by L<X509_verify_cert(3)>.
The validation process involves several steps and depends on multiple options.
The most important of them are detailed in the following sections.

In a nutshell, a valid chain of certificates needs to be constructed and checked
starting from the I<target certificate> that is to be validated and ending in a
trust anchor, which usually is a certificate that due to some policy is trusted.
Certificate validation can be performed in the context of a I<purpose>, which
is a high-level specification of the intended use of the target certificate,
such as C<sslserver> for (D)TLS servers, or (by default) for any purpose.

All certificates in the chain except the target ceritificate must be CA
certificates.
An X.509v3 certificate is considered a CA certificate
if it has a basicConstraints extension with the `CA` flag set.
If a pathLenConstraint is included then the chain is checked to satisfy it.
If a CA certificate has a keyUsage extension
then the latter must include the keyCertSign bit, and for proxy certificates
used for issuing a certificate it must include also the digitalSignature bit.

The details of how each OpenSSL command handles errors
are documented on the specific command page.

DANE support is documented in L<openssl-s_client(1)>,
L<SSL_CTX_dane_enable(3)>, L<SSL_set1_host(3)>,
L<X509_VERIFY_PARAM_set_flags(3)>, and L<X509_check_host(3)>.

=head2 Trust Anchors

In general, according to RFC 4158 and RFC 5280, a I<trust anchor> is just
a public key (with algorithm and any parameters) and an associated subject name
that in a suitable context is considered trusted for some purpose(s)
and thus is acceptable as the root of a chain of certificates.

In practice, trust anchors are given in the form of certificates.
Commonly they are self-signed root CA certificates.
Their most essential fields are the subjectPublicKeyInfo and
the subject distinguished name (DN), while the subject key identifier extension
is generally optional but highly recommended to be included in CA certificates
because they help chain building.
In addition to the requirements given in RFC 5280 for trust anchor handling,
OpenSSL performs on trust anchor certificates the same checks as on regular
CA certificates, in particular those regarding the validity period
and X.509v3 extensions like basic constraints and key usage.
Depending on the given validation purpose, in part even the extended key usage
is checked - for details see the L</Extended Key Usage> section below.

The most crucial input to certificate validation is a I<trust store>,
which includes a collection of certificates and validation options.
This is akin to what is used in the trust stores of Mozilla Firefox,
or Apple's and Microsoft's certificate stores, ...
By default all self-signed certificates in the trust store
are considered to be trust anchors, for all or for specified purposes.

Independent of any extended key usage (EKU) X.509v3 extension included,
from the OpenSSL perspective a trust anchor certificate should be augmented
with local trust attributes, giving an explicit designation for which
uses of a target certificate the certificate may serve as a trust anchor.
If this information is missing, it is by default trusted for all uses.
In PEM encoding, the presence of trust attributes
is indicated by the C<TRUSTED CERTIFICATE> string.
Such a designation provides a set of positive trust attributes
explicitly stating acceptance for the listed uses
and/or a set of negative trust attributes explicitly rejecting the listed uses.
These uses are encoded using the OID values defined for the extended key usages
that may be included in X.509v3 certificate extensions.
For the list of EKUs with currently predefined meaning
see the L</Extended Key Usage> section below.
The special EKU B<anyExtendedKeyUsage>
enables all uses when trusted or blocks all uses when rejected.

A certificate, which may be CA certificate or an end-entity certificate,
is considered a trust anchor for the intended use
if and only if all the following conditions hold:

=over 4

=item *

It is an element of the trust store.

=item *

It does not have a negative trust attribute rejecting
the EKU associated with the intended purpose.

=item *

It has a positive trust attribute accepting
the EKU associated with the intended purpose
or it does not have any positive trust attribute
and one of the following compatibility conditions apply:
It is self-signed or the B<-partial_chain> option is given
(which corresponds to the B<X509_V_FLAG_PARTIAL_CHAIN> flag being set).

=back

=head2 Certification Path Building

First, a certificate chain is built up starting from the target certificate
and ending in a trust anchor.
The goal is that for each certificate in the chain, except for the final one,
the subject of the successor is the issuer of the former certificate.
Since it often happens that the subject and issuer Distinguished Names
are not unique, the subject and issuer key identifier extensions,
if present in the certificates, are used to disambiguate conflicts.

The chain is built up iteratively, looking up each certificate in turn that
matches as an issuer of the current "subject" certificate as described below.
If there is more than one matching certificate, the algorithm uses
the first certificate found that has a suitable validity period,
otherwise the one with the latest expiration date of all matching certificates.
For efficiency, the algorithm does not allow for backtracking, thus
any further candidate issuer certificates that would match equally are ignored.

Certificate extensions are available since X.509v3,
and though many are optional, some are generally recommended or required.
For certificate chain building
the subjectKeyIdentifier and authorityKeyIdentifier extensions are very useful.
The subject alternative names (SAN) and issuer alternative names given in
subjectAltName or issuerAltName extensions are not relevant for chain building.

Once 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:

=over 4

=item *

Its subject Distinguished Name (DN)
matches the issuer DN of the subject certificate.

=item *

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.

=item *

The certificate signature algorithm used to sign the subject certificate
is supported and
equals the public key algorithm of the candidate issuer certificate.

item *

If the issuer certificate includes a key usage restriction,
it must allow for certificate signing (keyCertSign).

=back

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.

=head2 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 B<-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 no purpose is given explicitly then no such checks are done except for
CMS signature checking, where by default C<smimesign> is checked, and SSL/(D)TLS
connection setup, where by default C<sslserver> or C<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 L</Certificate Extensions> section below.

The third step is to check the trust settings on the last certificate or
trust anchor, which typically is given as a self-signed root CA certificate.
If specified, it must be trusted for the given use.
For compatibility, 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 C<notBefore> and C<notAfter> fields
is checked against the current system time.
The B<-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 B<-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.

=head1 OPTIONS

=head2 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 I<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
L<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.

=over 4

=item B<-CAfile> I<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.

=item B<-no-CAfile>

Do not load the default file of trusted certificates.

=item B<-CApath> I<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 L<openssl-rehash(1)> for information on creating this type of directory.

=item B<-no-CApath>

Do not use the default directory of trusted certificates.

=item B<-CAstore> I<uri>

Use I<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 C<file:> scheme, this acts as B<-CAfile> or
B<-CApath>, depending on if the URI indicates a single file or
directory.
See L<ossl_store-file(7)> for more information on the C<file:> scheme.

These certificates are also used when building the server certificate
chain (for example with L<openssl-s_server(1)>) or client certificate
chain (for example with L<openssl-s_time(1)>).

=item B<-no-CAstore>

Do not use the default store of trusted CA certificates.

=back

=head2 Verification Options

The certificate verification can be fine-tuned with the following flags.

=over 4

=item B<-verbose>

Print extra information about the operations being performed.

=item B<-attime> I<timestamp>

Perform validation checks using time specified by I<timestamp> and not
current system time. I<timestamp> is the number of seconds since
January 1, 1970 (i.e., the Unix Epoch).

=item B<-no_check_time>

This option suppresses checking the validity period of certificates and CRLs
against the current time. If option B<-attime> is used to specify
a verification time, the check is not suppressed.

=item B<-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:

=over 4

=item *

The basicConstraints of CA certificates must be marked critical.

=item *

CA certificates must explicitly include the keyUsage extension.

=item *

If a pathLenConstraint is given the key usage keyCertSign must be allowed.

=item *

The pathLenConstraint must not be given for non-CA certificates.

=item *

The issuer name of any certificate must not be empty.

=item *

The subject name of CA certs, certs with keyUsage crlSign, and certs
without subjectAlternativeName must not be empty.

=item *

If a subjectAlternativeName extension is given it must not be empty.

=item *

The signatureAlgorithm field and the cert signature must be consistent.

=item *

Any given authorityKeyIdentifier and any given subjectKeyIdentifier
must not be marked critical.

=item *

The authorityKeyIdentifier must be given for X.509v3 certs unless they
are self-signed.

=item *

The subjectKeyIdentifier must be given for all X.509v3 CA certs.

=back

=item B<-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.

=item B<-issuer_checks>

Ignored.

=item B<-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.

=item B<-crl_check_all>

Checks the validity of I<all> certificates in the chain by attempting
to look up valid CRLs.

=item B<-use_deltas>

Enable support for delta CRLs.

=item B<-extended_crl>

Enable extended CRL features such as indirect CRLs and alternate CRL
signing keys.

=item B<-suiteB_128_only>, B<-suiteB_128>, B<-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.

=item B<-auth_level> I<level>

Set the certificate chain authentication security level to I<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 I<level>.  The signature algorithm security level is
enforced for all the certificates in the chain except for the chain's
I<trust anchor>, which is either directly trusted or validated by means
other than its signature.  See L<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.

=item B<-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 is not self-signed and has no matching positive trust attributes)
but is an element of the trust store.
This certificate may be self-issued or belong to an intermediate CA.

=item B<-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.

=item B<-allow_proxy_certs>

Allow the verification of proxy certificates.

=item B<-trusted_first>

This option is on by default and cannot be disabled.

When constructing the certificate chain, the trusted certificates specified
via B<-CAfile>, B<-CApath>, B<-CAstore> or B<-trusted> are always used
before any certificates specified via B<-untrusted>.

=item B<-no_alt_chains>

Since B<-trusted_first> is always on, this option has no effect.

=item B<-trusted> I<file>

Parse I<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 B<-partial_chain> option is specified.
This option implies the B<-no-CAfile>, B<-no-CApath>, and B<-no-CAstore> options
and it cannot be used with the B<-CAfile>, B<-CApath> or B<-CAstore> options, so
only certificates specified using the B<-trusted> option are trust anchors.
This option may be used multiple times.

=item B<-untrusted> I<file>

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

=item B<-policy> I<arg>

Enable policy processing and add I<arg> to the user-initial-policy-set (see
RFC5280). The policy I<arg> can be an object name or an OID in numeric form.
This argument can appear more than once.

=item B<-explicit_policy>

Set policy variable require-explicit-policy (see RFC5280).

=item B<-policy_check>

Enables certificate policy processing.

=item B<-policy_print>

Print out diagnostics related to policy processing.

=item B<-inhibit_any>

Set policy variable inhibit-any-policy (see RFC5280).

=item B<-inhibit_map>

Set policy variable inhibit-policy-mapping (see RFC5280).

=item B<-purpose> I<purpose>

A high-level specification of the intended use of the target certificate.
Currently predefined purposes are C<sslclient>, C<sslserver>, C<nssslserver>,
C<smimesign>, C<smimeencrypt>, C<crlsign>, C<ocsphelper>, C<timestampsign>,
C<codesign> and C<any>.
If peer certificate verification is enabled, by default the TLS implementation
and thus the commands L<openssl-s_client(1)> and L<openssl-s_server(1)>
check for consistency with
TLS server (C<sslserver>) or TLS client use (C<sslclient>), respectively.
By default, CMS signature validation, which can be done via L<openssl-cms(1)>,
checks for consistency with S/MIME signing use (C<smimesign>).

While IETF RFC 5280 says that B<id-kp-serverAuth> and B<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.

For details on the checks performed see the L</Certificate Extensions> section.

=item B<-verify_depth> I<num>

Limit the certificate chain to I<num> intermediate CA certificates.
A maximal depth chain can have up to I<num>+2 certificates, since neither the
end-entity certificate nor the trust-anchor certificate count against the
B<-verify_depth> limit.

=item B<-verify_email> I<email>

Verify if I<email> matches the email address in Subject Alternative Name or
the email in the subject Distinguished Name.

=item B<-verify_hostname> I<hostname>

Verify if I<hostname> matches DNS name in Subject Alternative Name or
Common Name in the subject certificate.

=item B<-verify_ip> I<ip>

Verify if I<ip> matches the IP address in Subject Alternative Name of
the subject certificate.

=item B<-verify_name> I<name>

Use a set of verification parameters, also known as verification method,
identified by I<name>. The currently predefined methods are named C<ssl_client>,
C<ssl_server>, C<smime_sign> with alias C<pkcs7>, C<code_sign>, and C<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 B<-addtrust> and B<-addreject> options
for L<openssl-x509(1)>.

=back

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

=over 4

=item B<-xkey> I<infile>, B<-xcert> I<infile>, B<-xchain>

Specify an extra certificate, private key and certificate chain. These behave
in the same manner as the B<-cert>, B<-key> and B<-cert_chain> options.  When
specified, the callback returning the first valid chain will be in use by the
client.

=item B<-xchain_build>

Specify whether the application should build the certificate chain to be
provided to the server for the extra certificates via the B<-xkey>,
B<-xcert>, and B<-xchain> options.

=item B<-xcertform> B<DER>|B<PEM>|B<P12>

The input format for the extra certificate.
This option has no effect and is retained for backward compatibility only.

=item B<-xkeyform> B<DER>|B<PEM>|B<P12>

The input format for the extra key.
This option has no effect and is retained for backward compatibility only.

=back

=head2 Certificate Extensions

Options like B<-purpose> and B<-verify_name> trigger the processing of specific
certificate extensions, which determine what certificates can be used for.

The following two subsections on the B<basicConstraints> and B<keyUsage>
extensions and on X.509v1 certificates apply to I<all> CA certificates
regardless of any required purpose.

=head3 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. I<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.

=head3 Key Usage

If the keyUsage extension is present then additional restraints are
made on the uses of the certificate. A CA certificate I<must> have the
keyCertSign bit set if the keyUsage extension is present.
Further restrictions are checked depending on the required purpose, if any;
for details see the list given in the next subsection.

=head3 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 certificate, the key is allowed only for the uses specified,
while the special EKU B<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
C<sslclient>, C<nssslserver>, C<sslserver>, C<smimesign>, or C<smimeencrypt>,
it checks that any present EKU extension (that does not contain
B<anyExtendedKeyUsage>) contains the respective EKU as detailed below.
Moreover, it does these checks even for trust anchor certificates.

=head3 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 B<all>
CA certificates.

=over 4

=item B<(D)TLS Client> (C<sslclient>)

Any given extended key usage extension must allow for C<clientAuth>
("TLS WWW client authentication").

For target certificates,
the key usage must allow for C<digitalSignature> and/or C<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.

=item B<(D)TLS Server> (C<sslserver>)

Any given extended key usage extension must allow for C<serverAuth>
("TLS WWW server authentication") and/or include one of the SGC OIDs.

For target certificates, the key usage must
allow for C<digitalSignature>, C<keyEncipherment>, and/or C<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.

=item B<Netscape SSL Server> (C<nssslserver>)

In addition to what has been described for B<sslserver>, for a Netscape
SSL client to connect to an SSL server, its EE certificate must have the
B<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.

=item B<Common S/MIME Checks>

Any given extended key usage extension must allow for C<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.

=item B<S/MIME Signing> (C<smimesign>)

In addition to the common S/MIME checks, for target certificates
the key usage must allow for C<digitalSignature> and/or B<nonRepudiation> (or
its alias name B<contentCommitment>).

=item B<S/MIME Encryption> (C<smimeencrypt>)

In addition to the common S/MIME checks, for target certificates
the key usage must allow for C<keyEncipherment>.

=item B<CRL Signing> (C<crlsign>)

For target certificates, the key usage must allow for C<cRLSign>.

For all other certificates the normal CA checks apply.
Except in this case the basicConstraints extension must be present.

=item B<OCSP Helper> (C<ocsphelper>)

For target certificates, no checks are performed at this stage,
but special checks apply; see L<OCSP_basic_verify(3)>.

For all other certificates the normal CA checks apply.

=item B<Timestamp Signing> (C<timestampsign>)

For target certificates, if the key usage extension is present, it must include
C<digitalSignature> and/or C<nonRepudiation> (or its alias name
C<contentCommitment>) and must not include other bits.
The EKU extension must be present and contain C<timeStamping> only.
Moreover, it must be marked as critical.

For all other certificates the normal CA checks apply.

=item B<Code Signing> (C<codesign>)

For target certificates,
the key usage extension must be present and marked critical and
include <digitalSignature>, but must not include C<keyCertSign> nor C<cRLSign>.
The EKU extension must be present and contain C<codeSign>,
but must not include C<anyExtendedKeyUsage> nor C<serverAuth>.

For all other certificates the normal CA checks apply.

=back

=head1 BUGS

The issuer checks still suffer from limitations in the underlying X509_LOOKUP
API.  Trusted certificates with matching
subject name must appear in a file (as specified by the B<-CAfile> option),
a directory (as specified by B<-CApath>),
or a store (as specified by B<-CAstore>).
If there are multiple such matches, possibly in multiple locations,
only the first one (in the mentioned order of locations) is recognised.

=head1 SEE ALSO

L<X509_verify_cert(3)>,
L<OCSP_basic_verify(3)>,
L<openssl-verify(1)>,
L<openssl-ocsp(1)>,
L<openssl-ts(1)>,
L<openssl-s_client(1)>,
L<openssl-s_server(1)>,
L<openssl-smime(1)>,
L<openssl-cmp(1)>,
L<openssl-cms(1)>

=head1 HISTORY

Since OpenSSL 1.1.0, the B<-trusted_first> option is always enabled.

The checks enabled by B<-x509_strict> have been extended in OpenSSL 3.0.

=head1 COPYRIGHT

Copyright 2000-2025 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
L<https://www.openssl.org/source/license.html>.

=cut