Provided by: openssl_3.4.1-1ubuntu3_amd64 bug

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.4.1                                              2025-04-03                 OPENSSL-VERIFICATION-OPTIONS(1SSL)