diff options
author | David von Oheimb <dev@ddvo.net> | 2020-11-04 14:04:27 +0100 |
---|---|---|
committer | Dr. David von Oheimb <David.von.Oheimb@siemens.com> | 2020-12-05 18:05:30 +0100 |
commit | b6f18ed2effbefc52b392980f79cbe97f10bdb00 (patch) | |
tree | 0af900c00c80f18e2db7564a8bc8bf95274a79dd /doc/man1 | |
parent | 6b480ee369ae81a664518f440c2f7de94afc3b00 (diff) |
openssl.pod: Move verification doc to new doc/man1/openssl-verification-options.pod
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13315)
Diffstat (limited to 'doc/man1')
-rw-r--r-- | doc/man1/openssl-verification-options.pod | 398 | ||||
-rw-r--r-- | doc/man1/openssl-verify.pod.in | 2 | ||||
-rw-r--r-- | doc/man1/openssl.pod | 353 |
3 files changed, 401 insertions, 352 deletions
diff --git a/doc/man1/openssl-verification-options.pod b/doc/man1/openssl-verification-options.pod new file mode 100644 index 0000000000..8d7b2c1c67 --- /dev/null +++ b/doc/man1/openssl-verification-options.pod @@ -0,0 +1,398 @@ +=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 diff --git a/doc/man1/openssl-verify.pod.in b/doc/man1/openssl-verify.pod.in index 9e3e49b2d7..2b5a350553 100644 --- a/doc/man1/openssl-verify.pod.in +++ b/doc/man1/openssl-verify.pod.in @@ -147,7 +147,7 @@ B<X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY> error codes. =head1 SEE ALSO -L<openssl(1)>, +L<openssl-verification-options(1)>, L<openssl-x509(1)>, L<ossl_store-file(7)> diff --git a/doc/man1/openssl.pod b/doc/man1/openssl.pod index ace96274f9..b10ff1cf8c 100644 --- a/doc/man1/openssl.pod +++ b/doc/man1/openssl.pod @@ -304,6 +304,7 @@ Time Stamping Authority command. =item B<verify> X.509 Certificate Verification. +See also the L<openssl-verification-options(1)> manual page. =item B<version> @@ -762,359 +763,9 @@ This file can be used in a subsequent command invocation. =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 |