--- /dev/null
+=pod
+
+=head1 NAME
+
+openssl-verification-options - generic X.509 certificate verification options
+
+=head1 SYNOPSIS
+
+B<openssl>
+I<command>
+[ I<options> ... ]
+[ I<parameters> ... ]
+
+=head1 DESCRIPTION
+
+Many OpenSSL commands and various other uses of the crypto library function
+L<X509_verify_cert(3)> verify X.509 certificates. The details of how each
+command handles errors are documented on the specific command page.
+
+Certificate verification is a complicated process, consisting of
+a number of separate steps that are detailed in the following paragraphs.
+
+First, a certificate chain is built up starting from the target certificate
+and typically ending in a self-signed "root" CA certificate.
+It is an error if the whole chain cannot be built up
+unless the B<-partial_chain> option is given.
+The chain is built up iteratively, looking up in turn
+the certificate of the signer ("issuer") of the current certificate.
+If a certificate is found that appears to be its own issuer
+it is assumed to be the self-signed root, which must be trusted.
+
+The process of looking up the issuer's certificate itself involves a number
+of steps.
+All available certificates with a subject name that matches the issuer
+name of the current certificate are subject to further tests.
+The relevant authority key identifier components of the current certificate
+(if present) must match the subject key identifier (if present)
+and issuer and serial number 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).
+The last certificate (which typically is of a root CA) is always looked up
+in the trusted certificate list; an exact match must be found there.
+
+The second step is to check the extensions of every untrusted certificate
+for consistency with the supplied purpose.
+If the B<-purpose> option is not included then no checks are done.
+The target or "leaf" certificate must have extensions compatible with the
+supplied purpose and all other certificates must also be valid CA certificates.
+The precise extensions required are described in more detail in
+L<openssl-x509(1)/CERTIFICATE EXTENSIONS>.
+
+The third step is to check the trust settings on the last certficate,
+typically of a root CA.
+It should be trusted for the supplied purpose.
+For compatibility with previous versions of OpenSSL,
+a certificate with no trust settings is considered to be valid for all purposes.
+
+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 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 B<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 even if a I<complete> chain cannot be built to a
+self-signed trust-anchor, provided it is possible to construct a chain to a
+trusted certificate that might not be self-signed.
+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>
+
+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 B<-CAfile>, B<-CApath>, B<-CAstore> or B<-trusted> are always used
+before any certificates specified via B<-untrusted>.
+
+=item B<-no_alt_chains>
+
+As of OpenSSL 1.1.0, since B<-trusted_first> always on, this option has no
+effect.
+
+=item B<-trusted> I<file>
+
+Parse I<file> as a set of one or more certificates in PEM format.
+All certificates must be self-signed, unless 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 in the file 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 in PEM format.
+All certificates are untrusted certificates (typically of intermedate CAs)
+that may be used to
+construct a certificate chain from the subject 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 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>
+
+The intended use for the certificate. If this option is not specified, this
+command will not consider certificate purpose during chain verification.
+Currently accepted uses are B<sslclient>, B<sslserver>, B<nssslserver>,
+B<smimesign>, B<smimeencrypt>.
+
+=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 default verification policies like trust model and required certificate
+policies identified by I<name>.
+The trust model determines which auxiliary trust or reject OIDs are applicable
+to verifying the given certificate chain.
+See the B<-addtrust> and B<-addreject> options for L<openssl-x509(1)>.
+Supported policy names include: B<default>, B<pkcs7>, B<smime_sign>,
+B<ssl_client>, B<ssl_server>.
+These mimics the combinations of purpose and trust settings used in SSL, CMS
+and S/MIME.
+As of OpenSSL 1.1.0, the trust model is inferred from the purpose when not
+specified, so the B<-verify_name> options are functionally equivalent to the
+corresponding B<-purpose> settings.
+
+=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
+
+=head1 SEE ALSO
+
+L<X509_verify_cert(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
+
+The checks enabled by B<-x509_strict> have been extended in OpenSSL 3.0.
+
+=head1 COPYRIGHT
+
+Copyright 2000-2020 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
=head1 SEE ALSO
-L<openssl(1)>,
+L<openssl-verification-options(1)>,
L<openssl-x509(1)>,
L<ossl_store-file(7)>
=item B<verify>
X.509 Certificate Verification.
+See also the L<openssl-verification-options(1)> manual page.
=item B<version>
=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 Verification Options
-Many OpenSSL commands verify certificates. The details of how each
-command handles errors are documented on the specific command page.
-
-Verification is a complicated process, consisting of a number of separate
-steps that are detailed in the following paragraphs.
-
-First, a certificate chain is built up starting from the target certificate
-and typically ending in a self-signed "root" CA certificate.
-It is an error if the whole chain cannot be built up
-unless the B<-partial_chain> option is given.
-The chain is built up iteratively, looking up in turn
-the certificate of the signer ("issuer") of the current certificate.
-If a certificate is found that appears to be its own issuer
-it is assumed to be the self-signed root, which must be trusted.
-
-The process of looking up the issuer's certificate itself involves a number
-of steps.
-All available certificates with a subject name that matches the issuer
-name of the current certificate are subject to further tests.
-The relevant authority key identifier components of the current certificate
-(if present) must match the subject key identifier (if present)
-and issuer and serial number 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).
-The last certificate (which typically is of a root CA) is always looked up
-in the trusted certificate list; an exact match must be found there.
-
-The second step is to check the extensions of every untrusted certificate
-for consistency with the supplied purpose.
-If the B<-purpose> option is not included then no checks are done.
-The target or "leaf" certificate must have extensions compatible with the
-supplied purpose and all other certificates must also be valid CA certificates.
-The precise extensions required are described in more detail in
-L<openssl-x509(1)/CERTIFICATE EXTENSIONS>.
-
-The third step is to check the trust settings on the last certficate,
-typically of a root CA.
-It should be trusted for the supplied purpose.
-For compatibility with previous versions of OpenSSL,
-a certificate with no trust settings is considered to be valid for all purposes.
-
-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.
-
-The details of the processing steps 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 B<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 even if a I<complete> chain cannot be built to a
-self-signed trust-anchor, provided it is possible to construct a chain to a
-trusted certificate that might not be self-signed.
-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>
-
-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 B<-CAfile>, B<-CApath>, B<-CAstore> or B<-trusted> are always used
-before any certificates specified via B<-untrusted>.
-
-=item B<-no_alt_chains>
-
-As of OpenSSL 1.1.0, since B<-trusted_first> always on, this option has no
-effect.
-
-=item B<-trusted> I<file>
-
-Parse I<file> as a set of one or more certificates in PEM format.
-All certificates must be self-signed, unless 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 in the file 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 in PEM format.
-All certificates are untrusted certificates (typically of intermedate CAs)
-that may be used to
-construct a certificate chain from the subject 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 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>
-
-The intended use for the certificate. If this option is not specified, this
-command will not consider certificate purpose during chain verification.
-Currently accepted uses are B<sslclient>, B<sslserver>, B<nssslserver>,
-B<smimesign>, B<smimeencrypt>.
-
-=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 any email address in a Subject Alternative Name or
-(if no SAN is included) the email address in the subject Distinguished Name.
-
-=item B<-verify_hostname> I<hostname>
-
-Verify if I<hostname> matches any DNS name in a Subject Alternative Name or
-(if no SAN is included) the Common Name in the subject Distinguished Name.
-
-=item B<-verify_ip> I<ip>
-
-Verify if I<ip> matches any IP address in a Subject Alternative Name or
-(if no SAN is included) the Common Name in the subject Distinguished Name.
-
-=item B<-verify_name> I<name>
-
-Use default verification policies like trust model and required certificate
-policies identified by I<name>.
-The trust model determines which auxiliary trust or reject OIDs are applicable
-to verifying the given certificate chain.
-See the B<-addtrust> and B<-addreject> options for L<openssl-x509(1)>.
-Supported policy names include: B<default>, B<pkcs7>, B<smime_sign>,
-B<ssl_client>, B<ssl_server>.
-These mimics the combinations of purpose and trust settings used in SSL, CMS
-and S/MIME.
-As of OpenSSL 1.1.0, the trust model is inferred from the purpose when not
-specified, so the B<-verify_name> options are functionally equivalent to the
-corresponding B<-purpose> settings.
-
-=back
+See the L<openssl-verification-options(1)> manual page.
=head2 Name Format Options
flags such as X509_V_FLAG_X509_STRICT, and various other optional components
such as a callback function that allows customizing the verification outcome.
A complete description of the certificate verification process is contained in
-the L<openssl-verify(1)> manual page.
+the L<openssl-verification-options(1)> manual page.
Applications rarely call this function directly but it is used by
OpenSSL internally for certificate validation, in both the S/MIME and
. "B<-verify_ip>, B<-verify_name>, B<-x509_strict> B<-issuer_checks>\n"
. "\n"
. "Set various options of certificate chain verification.\n"
-. "See L<openssl(1)/Verification Options> for details.";
+. "See L<openssl-verification-options(1)/Verification Options> for details.";
# Extended validation options.
. "B<-xkeyform> B<DER>|B<PEM>\n"
. "\n"
. "Set extended certificate verification options.\n"
-. "See L<openssl(1)/Extended Verification Options> for details.";
+. "See L<openssl-verification-options(1)/Extended Verification Options> for details.";
# Name output options
$OpenSSL::safe::opt_name_synopsis = ""
projects / openssl.git / commitdiff