openssl-verification-options

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.

Do not load the default file of trusted certificates.

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.

Do not use the default directory of trusted certificates.

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)).

Do not use the default store of trusted CA certificates.

Print extra information about the operations being performed.

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).

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.

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:

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.

Ignored.

Checks end entity certificate validity by attempting to look up a valid CRL. If a valid CRL cannot be found an error occurs.

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

Enable support for delta CRLs.

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

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.

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. Th

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.

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 the verification of proxy certificates.

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.

As of OpenSSL 1.1.0, since -trusted_first always on, this option has no effect.

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.

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.

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.

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

Enables certificate policy processing.

Print out diagnostics related to policy processing.

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

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

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 sig

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 if email matches the email address in Subject Alternative Name or the email in the subject Distinguished Name.

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

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

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

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.

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.

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

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