TrustedCertificateOptions
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 truststore.
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.
-CAfilefile
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.
-CApathdir
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.
-CAstoreuri
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.
VerificationOptions
The certificate verification can be fine-tuned with the following flags.
-verbose
Print extra information about the operations being performed.
-attimetimestamp
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_levellevel
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 trustanchor, 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.
-trustedfile
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.
-untrustedfile
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.
-policyarg
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).
-purposepurpose
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_depthnum
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_emailemail
Verify if email matches the email address in Subject Alternative Name or the email in the subject
Distinguished Name.
-verify_hostnamehostname
Verify if hostname matches DNS name in Subject Alternative Name or Common Name in the subject
certificate.
-verify_ipip
Verify if ip matches the IP address in Subject Alternative Name of the subject certificate.
-verify_namename
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).
ExtendedVerificationOptions
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.
-xkeyinfile, -xcertinfile, -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.
-xcertformDER|PEM|P12
The input format for the extra certificate. This option has no effect and is retained for backward
compatibility only.
-xkeyformDER|PEM|P12
The input format for the extra key. This option has no effect and is retained for backward
compatibility only.
CertificateExtensions
Options like -purpose and -verify_name trigger the processing of specific certificate extensions, which
determine what certificates can be used for.
BasicConstraints
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.
KeyUsage
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.
ExtendedKeyUsage
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.
ChecksImpliedbySpecificPredefinedPolicies
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)TLSClient ("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)TLSServer ("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.
NetscapeSSLServer ("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.
CommonS/MIMEChecks
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/MIMESigning ("smimesign")
In addition to the common S/MIME checks, for target certficiates the key usage must allow for
"digitalSignature" and/or nonRepudiation.
S/MIMEEncryption ("smimeencrypt")
In addition to the common S/MIME checks, for target certficiates the key usage must allow for
"keyEncipherment".
CRLSigning ("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.
OCSPHelper ("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.
TimestampSigning ("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.
CodeSigning ("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.
Install Now
PNG Icons
Emojis
