{
"mode": "man",
"parameter": "openssl-verification-options",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-verification-options/1/json",
"generated": "2026-08-14T03:40:13Z",
"synopsis": "openssl command [ options ... ] [ parameters ... ]",
"sections": {
"NAME": {
"content": "openssl-verification-options - generic X.509 certificate verification options\n",
"subsections": []
},
"SYNOPSIS": {
"content": "openssl command [ options ... ] [ parameters ... ]\n",
"subsections": []
},
"DESCRIPTION": {
"content": "There are many situations where X.509 certificates are verified within the OpenSSL libraries\nand in various OpenSSL commands.\n\nCertificate verification is implemented by X509verifycert(3). It is a complicated process\nconsisting of a number of steps and depending on numerous options. The most important of\nthem are detailed in the following sections.\n\nIn a nutshell, a valid chain of certificates needs to be built up and verified starting from\nthe target certificate that is to be verified and ending in a certificate that due to some\npolicy is trusted. Verification is done relative to the given purpose, which is the intended\nuse of the target certificate, such as SSL server, or by default for any purpose.\n\nThe details of how each OpenSSL command handles errors are documented on the specific command\npage.\n\nDANE support is documented in openssl-sclient(1), SSLCTXdaneenable(3), SSLset1host(3),\nX509VERIFYPARAMsetflags(3), and X509checkhost(3).\n",
"subsections": [
{
"name": "Trust Anchors",
"content": "In general, according to RFC 4158 and RFC 5280, a trust anchor is any public key and related\nsubject distinguished name (DN) that for some reason is considered trusted and thus is\nacceptable as the root of a chain of certificates.\n\nIn practice, trust anchors are given in the form of certificates, where their essential\nfields are the public key and the subject DN. In addition to the requirements in RFC 5280,\nOpenSSL checks the validity period of such certificates and makes use of some further fields.\nIn particular, the subject key identifier extension, if present, is used for matching trust\nanchors during chain building.\n\nIn the most simple and common case, trust anchors are by default all self-signed \"root\" CA\ncertificates that are placed in the trust store, which is a collection of certificates that\nare trusted for certain uses. This is akin to what is used in the trust stores of Mozilla\nFirefox, or Apple's and Microsoft's certificate stores, ...\n\nFrom the OpenSSL perspective, a trust anchor is a certificate that should be augmented with\nan explicit designation for which uses of a target certificate the certificate may serve as a\ntrust anchor. In PEM encoding, this is indicated by the \"TRUSTED CERTIFICATE\" string. Such\na designation provides a set of positive trust attributes explicitly stating trust for the\nlisted purposes and/or a set of negative trust attributes explicitly rejecting the use for\nthe listed purposes. The purposes are encoded using the values defined for the extended key\nusages (EKUs) that may be given in X.509 extensions of end-entity certificates. See also the\n\"Extended Key Usage\" section below.\n\nThe currently recognized uses are clientAuth (SSL client use), serverAuth (SSL server use),\nemailProtection (S/MIME email use), codeSigning (object signer use), OCSPSigning (OCSP\nresponder use), OCSP (OCSP request use), timeStamping (TSA server use), and\nanyExtendedKeyUsage. As of OpenSSL 1.1.0, the last of these blocks all uses when rejected or\nenables all uses when trusted.\n\nA certificate, which may be CA certificate or an end-entity certificate, is considered a\ntrust anchor for the given use if and only if all the following conditions hold:\n\n• It is an an element of the trust store.\n\n• It does not have a negative trust attribute rejecting the given use.\n\n• It has a positive trust attribute accepting the given use or (by default) one of the\nfollowing compatibility conditions apply: It is self-signed or the -partialchain option\nis given (which corresponds to the X509VFLAGPARTIALCHAIN flag being set).\n"
},
{
"name": "Certification Path Building",
"content": "First, a certificate chain is built up starting from the target certificate and ending in a\ntrust anchor.\n\nThe chain is built up iteratively, looking up in turn a certificate with suitable key usage\nthat matches as an issuer of the current \"subject\" certificate as described below. If there\nis such a certificate, the first one found that is currently valid is taken, otherwise the\none that expired most recently of all such certificates. For efficiency, no backtracking is\nperformed, thus any further candidate issuer certificates that would match equally are\nignored.\n\nWhen a self-signed certificate has been added, chain construction stops. In this case it\nmust fully match a trust anchor, otherwise chain building fails.\n\nA candidate issuer certificate matches a subject certificate if all of the following\nconditions hold:\n\n• Its subject name matches the issuer name of the subject certificate.\n\n• If the subject certificate has an authority key identifier extension, each of its sub-\nfields equals the corresponding subject key identifier, serial number, and issuer field\nof the candidate issuer certificate, as far as the respective fields are present in both\ncertificates.\n\n• The certificate signature algorithm used to sign the subject certificate is supported and\nequals the public key algorithm of the candidate issuer certificate.\n\nThe lookup first searches for issuer certificates in the trust store. If it does not find a\nmatch there it consults the list of untrusted (\"intermediate\" CA) certificates, if provided.\n"
},
{
"name": "Certification Path Validation",
"content": "When the certificate chain building process was successful the chain components and their\nlinks are checked thoroughly.\n\nThe first step is to check that each certificate is well-formed. Part of these checks are\nenabled only if the -x509strict option is given.\n\nThe second step is to check the extensions of every untrusted certificate for consistency\nwith the supplied purpose. If the -purpose option is not given then no such checks are done\nexcept for SSL/TLS connection setup, where by default \"sslserver\" or \"sslclient\", are\nchecked. The target or \"leaf\" certificate, as well as any other untrusted certificates, must\nhave extensions compatible with the specified purpose. All certificates except the target or\n\"leaf\" must also be valid CA certificates. The precise extensions required are described in\nmore detail in \"CERTIFICATE EXTENSIONS\" in openssl-x509(1).\n\nThe third step is to check the trust settings on the last certificate (which typically is a\nself-signed root CA certificate). It must be trusted for the given use. For compatibility\nwith previous versions of OpenSSL, a self-signed certificate with no trust attributes is\nconsidered to be valid for all uses.\n\nThe fourth, and final, step is to check the validity of the certificate chain. For each\nelement in the chain, including the root CA certificate, the validity period as specified by\nthe \"notBefore\" and \"notAfter\" fields is checked against the current system time. The"
},
{
"name": "-attime",
"content": "is checked as well (except for the signature of the typically self-signed root CA\ncertificate, which is verified only if the -checksssig option is given). When verifying a\ncertificate signature the keyUsage extension (if present) of the candidate issuer certificate\nis checked to permit digitalSignature for signing proxy certificates or to permit keyCertSign\nfor signing other certificates, respectively. If all operations complete successfully then\ncertificate is considered valid. If any operation fails then the certificate is not valid.\n"
}
]
},
"OPTIONS": {
"content": "",
"subsections": [
{
"name": "Trusted Certificate Options",
"content": "The following options specify how to supply the certificates that can be used as trust\nanchors for certain uses. As mentioned, a collection of such certificates is called a trust\nstore.\n\nNote that OpenSSL does not provide a default set of trust anchors. Many Linux distributions\ninclude a system default and configure OpenSSL to point to that. Mozilla maintains an\ninfluential trust store that can be found at\n.\n\nThe certificates to add to the trust store can be specified using following options.\n"
},
{
"name": "-CAfile _",
"content": "Load the specified file which contains a certificate or several of them in case the input\nis in PEM or PKCS#12 format. PEM-encoded certificates may also have trust attributes\nset.\n"
},
{
"name": "-no-CAfile",
"content": "Do not load the default file of trusted certificates.\n"
},
{
"name": "-CApath _",
"content": "Use the specified directory as a collection of trusted certificates, i.e., a trust store.\nFiles should be named with the hash value of the X.509 SubjectName of each certificate.\nThis is so that the library can extract the IssuerName, hash it, and directly lookup the\nfile to get the issuer certificate. See openssl-rehash(1) for information on creating\nthis type of directory.\n"
},
{
"name": "-no-CApath",
"content": "Do not use the default directory of trusted certificates.\n"
},
{
"name": "-CAstore _",
"content": "Use uri as a store of CA certificates. The URI may indicate a single certificate, as\nwell as a collection of them. With URIs in the \"file:\" scheme, this acts as -CAfile or\n-CApath, depending on if the URI indicates a single file or directory. See\nosslstore-file(7) for more information on the \"file:\" scheme.\n\nThese certificates are also used when building the server certificate chain (for example\nwith openssl-sserver(1)) or client certificate chain (for example with\nopenssl-stime(1)).\n"
},
{
"name": "-no-CAstore",
"content": "Do not use the default store of trusted CA certificates.\n"
},
{
"name": "Verification Options",
"content": "The certificate verification can be fine-tuned with the following flags.\n"
},
{
"name": "-verbose",
"content": "Print extra information about the operations being performed.\n"
},
{
"name": "-attime _",
"content": "Perform validation checks using time specified by timestamp and not current system time.\ntimestamp is the number of seconds since January 1, 1970 (i.e., the Unix Epoch).\n"
},
{
"name": "-no_check_time",
"content": "This option suppresses checking the validity period of certificates and CRLs against the\ncurrent time. If option -attime is used to specify a verification time, the check is not\nsuppressed.\n"
},
{
"name": "-x509_strict",
"content": "This disables non-compliant workarounds for broken certificates. Thus errors are thrown\non certificates not compliant with RFC 5280.\n\nWhen this option is set, among others, the following certificate well-formedness\nconditions are checked:\n\n• The basicConstraints of CA certificates must be marked critical.\n\n• CA certificates must explicitly include the keyUsage extension.\n\n• If a pathlenConstraint is given the key usage keyCertSign must be allowed.\n\n• The pathlenConstraint must not be given for non-CA certificates.\n\n• The issuer name of any certificate must not be empty.\n\n• The subject name of CA certs, certs with keyUsage crlSign, and certs without\nsubjectAlternativeName must not be empty.\n\n• If a subjectAlternativeName extension is given it must not be empty.\n\n• The signatureAlgorithm field and the cert signature must be consistent.\n\n• Any given authorityKeyIdentifier and any given subjectKeyIdentifier must not be\nmarked critical.\n\n• The authorityKeyIdentifier must be given for X.509v3 certs unless they are self-\nsigned.\n\n• The subjectKeyIdentifier must be given for all X.509v3 CA certs.\n"
},
{
"name": "-ignore_critical",
"content": "Normally if an unhandled critical extension is present that is not supported by OpenSSL\nthe certificate is rejected (as required by RFC5280). If this option is set critical\nextensions are ignored.\n"
},
{
"name": "-issuer_checks",
"content": "Ignored.\n"
},
{
"name": "-crl_check",
"content": "Checks end entity certificate validity by attempting to look up a valid CRL. If a valid\nCRL cannot be found an error occurs.\n"
},
{
"name": "-crl_check_all",
"content": "Checks the validity of all certificates in the chain by attempting to look up valid CRLs.\n"
},
{
"name": "-use_deltas",
"content": "Enable support for delta CRLs.\n"
},
{
"name": "-extended_crl",
"content": "Enable extended CRL features such as indirect CRLs and alternate CRL signing keys.\n"
},
{
"name": "-suiteB_128_only -suiteB_128 -suiteB_192",
"content": "Enable the Suite B mode operation at 128 bit Level of Security, 128 bit or 192 bit, or\nonly 192 bit Level of Security respectively. See RFC6460 for details. In particular the\nsupported signature algorithms are reduced to support only ECDSA and SHA256 or SHA384 and\nonly the elliptic curves P-256 and P-384.\n"
},
{
"name": "-auth_level _",
"content": "Set the certificate chain authentication security level to level. The authentication\nsecurity level determines the acceptable signature and public key strength when verifying\ncertificate chains. For a certificate chain to validate, the public keys of all the\ncertificates must meet the specified security level. The signature algorithm security\nlevel is enforced for all the certificates in the chain except for the chain's trust\nanchor, which is either directly trusted or validated by means other than its signature.\nSee SSLCTXsetsecuritylevel(3) for the definitions of the available levels. The\ndefault security level is -1, or \"not set\". At security level 0 or lower all algorithms\nare acceptable. Security level 1 requires at least 80-bit-equivalent security and is\nbroadly interoperable, though it will, for example, reject MD5 signatures or RSA keys\nshorter than 1024 bits.\n"
},
{
"name": "-partial_chain",
"content": "Allow verification to succeed if an incomplete chain can be built. That is, a chain\nending in a certificate that normally would not be trusted (because it has no matching\npositive trust attributes and is not self-signed) but is an element of the trust store.\nThis certificate may be self-issued or belong to an intermediate CA.\n"
},
{
"name": "-check_ss_sig",
"content": "Verify the signature of the last certificate in a chain if the certificate is supposedly\nself-signed. This is prohibited and will result in an error if it is a non-conforming CA\ncertificate with key usage restrictions not including the keyCertSign bit. This\nverification is disabled by default because it doesn't add any security.\n"
},
{
"name": "-allow_proxy_certs",
"content": "Allow the verification of proxy certificates.\n"
},
{
"name": "-trusted_first",
"content": "As of OpenSSL 1.1.0 this option is on by default and cannot be disabled.\n\nWhen constructing the certificate chain, the trusted certificates specified via -CAfile,\n-CApath, -CAstore or -trusted are always used before any certificates specified via\n-untrusted.\n"
},
{
"name": "-no_alt_chains",
"content": "As of OpenSSL 1.1.0, since -trustedfirst always on, this option has no effect.\n"
},
{
"name": "-trusted _",
"content": "Parse file as a set of one or more certificates. Each of them qualifies as trusted if\nhas a suitable positive trust attribute or it is self-signed or the -partialchain option\nis specified. This option implies the -no-CAfile, -no-CApath, and -no-CAstore options\nand it cannot be used with the -CAfile, -CApath or -CAstore options, so only certificates\nspecified using the -trusted option are trust anchors. This option may be used multiple\ntimes.\n"
},
{
"name": "-untrusted _",
"content": "Parse file as a set of one or more certificates. All certificates (typically of\nintermediate CAs) are considered untrusted and may be used to construct a certificate\nchain from the target certificate to a trust anchor. This option may be used multiple\ntimes.\n"
},
{
"name": "-policy _",
"content": "Enable policy processing and add arg to the user-initial-policy-set (see RFC5280). The\npolicy arg can be an object name an OID in numeric form. This argument can appear more\nthan once.\n"
},
{
"name": "-explicit_policy",
"content": "Set policy variable require-explicit-policy (see RFC5280).\n"
},
{
"name": "-policy_check",
"content": "Enables certificate policy processing.\n"
},
{
"name": "-policy_print",
"content": "Print out diagnostics related to policy processing.\n"
},
{
"name": "-inhibit_any",
"content": "Set policy variable inhibit-any-policy (see RFC5280).\n"
},
{
"name": "-inhibit_map",
"content": "Set policy variable inhibit-policy-mapping (see RFC5280).\n"
},
{
"name": "-purpose _",
"content": "The intended use for the certificate. Currently defined purposes are \"sslclient\",\n\"sslserver\", \"nssslserver\", \"smimesign\", \"smimeencrypt\", \"crlsign\", \"ocsphelper\",\n\"timestampsign\", and \"any\". If peer certificate verification is enabled, by default the\nTLS implementation as well as the commands sclient and sserver check for consistency\nwith TLS server or TLS client use, respectively.\n\nWhile IETF RFC 5280 says that id-kp-serverAuth and id-kp-clientAuth are only for WWW use,\nin practice they are used for all kinds of TLS clients and servers, and this is what\nOpenSSL assumes as well.\n"
},
{
"name": "-verify_depth _",
"content": "Limit the certificate chain to num intermediate CA certificates. A maximal depth chain\ncan have up to num+2 certificates, since neither the end-entity certificate nor the\ntrust-anchor certificate count against the -verifydepth limit.\n"
},
{
"name": "-verify_email _",
"content": "Verify if email matches the email address in Subject Alternative Name or the email in the\nsubject Distinguished Name.\n"
},
{
"name": "-verify_hostname _",
"content": "Verify if hostname matches DNS name in Subject Alternative Name or Common Name in the\nsubject certificate.\n"
},
{
"name": "-verify_ip _",
"content": "Verify if ip matches the IP address in Subject Alternative Name of the subject\ncertificate.\n"
},
{
"name": "-verify_name _",
"content": "Use default verification policies like trust model and required certificate policies\nidentified by name. The trust model determines which auxiliary trust or reject OIDs are\napplicable to verifying the given certificate chain. They can be given using the\n-addtrust and -addreject options for openssl-x509(1). Supported policy names include:\ndefault, pkcs7, smimesign, sslclient, sslserver. These mimics the combinations of\npurpose and trust settings used in SSL, CMS and S/MIME. As of OpenSSL 1.1.0, the trust\nmodel is inferred from the purpose when not specified, so the -verifyname options are\nfunctionally equivalent to the corresponding -purpose settings.\n"
},
{
"name": "Extended Verification Options",
"content": "Sometimes there may be more than one certificate chain leading to an end-entity certificate.\nThis usually happens when a root or intermediate CA signs a certificate for another a CA in\nother organization. Another reason is when a CA might have intermediates that use two\ndifferent signature formats, such as a SHA-1 and a SHA-256 digest.\n\nThe following options can be used to provide data that will allow the OpenSSL command to\ngenerate an alternative chain.\n"
},
{
"name": "-xkey _ -xcert _ -xchain",
"content": "Specify an extra certificate, private key and certificate chain. These behave in the same\nmanner as the -cert, -key and -certchain options. When specified, the callback\nreturning the first valid chain will be in use by the client.\n"
},
{
"name": "-xchain_build",
"content": "Specify whether the application should build the certificate chain to be provided to the\nserver for the extra certificates via the -xkey, -xcert, and -xchain options.\n"
},
{
"name": "-xcertform DER",
"content": "The input format for the extra certificate. This option has no effect and is retained\nfor backward compatibility only.\n"
},
{
"name": "-xkeyform DER",
"content": "The input format for the extra key. This option has no effect and is retained for\nbackward compatibility only.\n"
},
{
"name": "Certificate Extensions",
"content": "Options like -purpose lead to checking the certificate extensions, which determine what the\ntarget certificate and intermediate CA certificates can be used for.\n\nBasic Constraints\n\nThe basicConstraints extension CA flag is used to determine whether the certificate can be\nused as a CA. If the CA flag is true then it is a CA, if the CA flag is false then it is not\na CA. All CAs should have the CA flag set to true.\n\nIf the basicConstraints extension is absent, which includes the case that it is an X.509v1\ncertificate, then the certificate is considered to be a \"possible CA\" and other extensions\nare checked according to the intended use of the certificate. The treatment of certificates\nwithout basicConstraints as a CA is presently supported, but this could change in the future.\n\nKey Usage\n\nIf the keyUsage extension is present then additional restraints are made on the uses of the\ncertificate. A CA certificate must have the keyCertSign bit set if the keyUsage extension is\npresent.\n\nExtended Key Usage\n\nThe extKeyUsage (EKU) extension places additional restrictions on the certificate uses. If\nthis extension is present (whether critical or not) the key can only be used for the purposes\nspecified.\n\nA complete description of each check is given below. The comments about basicConstraints and\nkeyUsage and X.509v1 certificates above apply to all CA certificates.\n"
},
{
"name": "SSL Client",
"content": "The extended key usage extension must be absent or include the \"web client\nauthentication\" OID. The keyUsage extension must be absent or it must have the\ndigitalSignature bit set. The Netscape certificate type must be absent or it must have\nthe SSL client bit set.\n"
},
{
"name": "SSL Client CA",
"content": "The extended key usage extension must be absent or include the \"web client\nauthentication\" OID. The Netscape certificate type must be absent or it must have the\nSSL CA bit set. This is used as a work around if the basicConstraints extension is\nabsent.\n"
},
{
"name": "SSL Server",
"content": "The extended key usage extension must be absent or include the \"web server\nauthentication\" and/or one of the SGC OIDs. The keyUsage extension must be absent or it\nmust have the digitalSignature, the keyEncipherment set or both bits set. The Netscape\ncertificate type must be absent or have the SSL server bit set.\n"
},
{
"name": "SSL Server CA",
"content": "The extended key usage extension must be absent or include the \"web server\nauthentication\" and/or one of the SGC OIDs. The Netscape certificate type must be absent\nor the SSL CA bit must be set. This is used as a work around if the basicConstraints\nextension is absent.\n"
},
{
"name": "Netscape SSL Server",
"content": "For Netscape SSL clients to connect to an SSL server it must have the keyEncipherment bit\nset if the keyUsage extension is present. This isn't always valid because some cipher\nsuites use the key for digital signing. Otherwise it is the same as a normal SSL server.\n"
},
{
"name": "Common S/MIME Client Tests",
"content": "The extended key usage extension must be absent or include the \"email protection\" OID.\nThe Netscape certificate type must be absent or should have the S/MIME bit set. If the\nS/MIME bit is not set in the Netscape certificate type then the SSL client bit is\ntolerated as an alternative but a warning is shown. This is because some Verisign\ncertificates don't set the S/MIME bit.\n"
},
{
"name": "S/MIME Signing",
"content": "In addition to the common S/MIME client tests the digitalSignature bit or the\nnonRepudiation bit must be set if the keyUsage extension is present.\n"
},
{
"name": "S/MIME Encryption",
"content": "In addition to the common S/MIME tests the keyEncipherment bit must be set if the\nkeyUsage extension is present.\n\nS/MIME CA\nThe extended key usage extension must be absent or include the \"email protection\" OID.\nThe Netscape certificate type must be absent or must have the S/MIME CA bit set. This is\nused as a work around if the basicConstraints extension is absent.\n"
},
{
"name": "CRL Signing",
"content": "The keyUsage extension must be absent or it must have the CRL signing bit set.\n"
},
{
"name": "CRL Signing CA",
"content": "The normal CA tests apply. Except in this case the basicConstraints extension must be\npresent.\n"
}
]
},
"BUGS": {
"content": "The issuer checks still suffer from limitations in the underlying X509LOOKUP API. One\nconsequence of this is that trusted certificates with matching subject name must appear in a\nfile (as specified by the -CAfile option), a directory (as specified by -CApath), or a store\n(as specified by -CAstore). If there are multiple such matches, possibly in multiple\nlocations, only the first one (in the mentioned order of locations) is recognised.\n",
"subsections": []
},
"SEE ALSO": {
"content": "X509verifycert(3), openssl-verify(1), openssl-ocsp(1), openssl-ts(1), openssl-sclient(1),\nopenssl-sserver(1), openssl-smime(1), openssl-cmp(1), openssl-cms(1)\n",
"subsections": []
},
"HISTORY": {
"content": "The checks enabled by -x509strict have been extended in OpenSSL 3.0.\n",
"subsections": []
},
"COPYRIGHT": {
"content": "Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.\n\nLicensed under the Apache License 2.0 (the \"License\"). You may not use this file except in\ncompliance with the License. You can obtain a copy in the file LICENSE in the source\ndistribution or at .\n\n3.0.13 2026-07-29 OPENSSL-VERIFICATION-OPTIONS(1SSL)",
"subsections": []
}
},
"summary": "openssl-verification-options - generic X.509 certificate verification options",
"flags": [
{
"flag": "",
"long": null,
"arg": null,
"description": "Load the specified file which contains a certificate or several of them in case the input is in PEM or PKCS#12 format. PEM-encoded certificates may also have trust attributes set."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Do not load the default file of trusted certificates."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Do not use the default directory of trusted certificates."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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 osslstore-file(7) for more information on the \"file:\" scheme. These certificates are also used when building the server certificate chain (for example with openssl-sserver(1)) or client certificate chain (for example with openssl-stime(1))."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Do not use the default store of trusted CA certificates."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Print extra information about the operations being performed."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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)."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Ignored."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Checks end entity certificate validity by attempting to look up a valid CRL. If a valid CRL cannot be found an error occurs."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Checks the validity of all certificates in the chain by attempting to look up valid CRLs."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Enable support for delta CRLs."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Enable extended CRL features such as indirect CRLs and alternate CRL signing keys."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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 SSLCTXsetsecuritylevel(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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Allow the verification of proxy certificates."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "As of OpenSSL 1.1.0, since -trustedfirst always on, this option has no effect."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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 -partialchain 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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Enable policy processing and add arg to the user-initial-policy-set (see RFC5280). The policy arg can be an object name an OID in numeric form. This argument can appear more than once."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Set policy variable require-explicit-policy (see RFC5280)."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Enables certificate policy processing."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Print out diagnostics related to policy processing."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Set policy variable inhibit-any-policy (see RFC5280)."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Set policy variable inhibit-policy-mapping (see RFC5280)."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "The intended use for the certificate. Currently defined purposes are \"sslclient\", \"sslserver\", \"nssslserver\", \"smimesign\", \"smimeencrypt\", \"crlsign\", \"ocsphelper\", \"timestampsign\", and \"any\". If peer certificate verification is enabled, by default the TLS implementation as well as the commands sclient and sserver check for consistency with TLS server or TLS client use, respectively. 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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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 -verifydepth limit."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Verify if email matches the email address in Subject Alternative Name or the email in the subject Distinguished Name."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Verify if hostname matches DNS name in Subject Alternative Name or Common Name in the subject certificate."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Verify if ip matches the IP address in Subject Alternative Name of the subject certificate."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Use default verification policies like trust model and required certificate policies identified by name. 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). Supported policy names include: default, pkcs7, smimesign, sslclient, sslserver. 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 -verifyname options are functionally equivalent to the corresponding -purpose settings."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "Specify an extra certificate, private key and certificate chain. These behave in the same manner as the -cert, -key and -certchain options. When specified, the callback returning the first valid chain will be in use by the client."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "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."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "The input format for the extra certificate. This option has no effect and is retained for backward compatibility only."
},
{
"flag": "",
"long": null,
"arg": null,
"description": "The input format for the extra key. This option has no effect and is retained for backward compatibility only."
}
],
"examples": [],
"see_also": [
{
"name": "X509verifycert",
"section": "3",
"url": "https://www.chedong.com/phpMan.php/man/X509verifycert/3/json"
},
{
"name": "openssl-verify",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-verify/1/json"
},
{
"name": "openssl-ocsp",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-ocsp/1/json"
},
{
"name": "openssl-ts",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-ts/1/json"
},
{
"name": "openssl-sclient",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-sclient/1/json"
},
{
"name": "openssl-sserver",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-sserver/1/json"
},
{
"name": "openssl-smime",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-smime/1/json"
},
{
"name": "openssl-cmp",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-cmp/1/json"
},
{
"name": "openssl-cms",
"section": "1",
"url": "https://www.chedong.com/phpMan.php/man/openssl-cms/1/json"
}
]
}