It has a positive trust attribute accepting the given use or (by default) one of the following compatibility conditions apply: It is self-signed or the -partial_chain option is given (which corresponds to the X509_V_FLAG_PARTIAL_CHAIN flag being set).įirst, a certificate chain is built up starting from the target certificate and ending in a trust anchor. It does not have a negative trust attribute rejecting the given use. As of OpenSSL 1.1.0, the last of these blocks all uses when rejected or enables all uses when trusted.Ī certificate, which may be CA certificate or an end-entity certificate, is considered a trust anchor for the given use if and only if all the following conditions hold: The currently recognized uses are clientAuth (SSL client use), serverAuth (SSL server use), emailProtection (S/MIME email use), codeSigning (object signer use), OCSPSigning (OCSP responder use), OCSP (OCSP request use), timeStamping (TSA server use), and anyExtendedKeyUsage. See also the "Extended Key Usage" section below. The purposes are encoded using the values defined for the extended key usages (EKUs) that may be given in X.509 extensions of end-entity certificates. Such a designation provides a set of positive trust attributes explicitly stating trust for the listed purposes and/or a set of negative trust attributes explicitly rejecting the use for the listed purposes. In PEM encoding, this is indicated by the TRUSTED CERTIFICATE string. įrom the OpenSSL perspective, a trust anchor is a certificate that should be augmented with an explicit designation for which uses of a target certificate the certificate may serve as a trust anchor. This is akin to what is used in the trust stores of Mozilla Firefox, or Apple's and Microsoft's certificate stores. In the most simple and common case, trust anchors are by default all self-signed "root" CA certificates that are placed in the trust store, which is a collection of certificates that are trusted for certain uses. In particular, the subject key identifier extension, if present, is used for matching trust anchors during chain building. In addition to the requirements in RFC 5280, OpenSSL checks the validity period of such certificates and makes use of some further fields. In practice, trust anchors are given in the form of certificates, where their essential fields are the public key and the subject DN. In general, according to RFC 4158 and RFC 5280, a trust anchor is any public key and related subject distinguished name (DN) that for some reason is considered trusted and thus is acceptable as the root of a chain of certificates. The details of how each OpenSSL command handles errors are documented on the specific command page.ĭANE support is documented in openssl-s_client(1), SSL_CTX_dane_enable(3), SSL_set1_host(3), X509_VERIFY_PARAM_set_flags(3), and X509_check_host(3). Verification is done relative to the given purpose, which is the intended use of the target certificate, such as SSL server, or by default for any purpose. In a nutshell, a valid chain of certificates needs to be built up and verified starting from the target certificate that is to be verified and ending in a certificate that due to some policy is trusted. The most important of them are detailed in the following sections. It is a complicated process consisting of a number of steps and depending on numerous options. There are many situations where X.509 certificates are verified within the OpenSSL libraries and in various OpenSSL commands.Ĭertificate verification is implemented by X509_verify_cert(3). Openssl dgst -sha256 -verify tstpub.pem -signature tst.Openssl-verification-options - generic X.509 certificate verification options SYNOPSIS # verify the signature with non-matching public key Openssl dgst -sha256 -sign altpri.pem -out tst.sig fil Openssl dgst -sha256 -verify tstpub.pem -signature tst.sig fil # verify the signature with matching public key Openssl dgst -sha256 -sign tstpri.pem -out tst.sig fil # create a file fil (any content will do) Openssl ecparam -genkey -noout -name secp256k1 -out altpri.pem # generate an alternate secp256k1 private key Openssl ec -in tstpri.pem -pubout -out tstpub.pem >/dev/null Openssl ecparam -genkey -noout -name secp256k1 -out tstpri.pem If there is some failure, then private and public key do not match (or the program is misused, incomptible with the key formats, or broken).Įxample with openssl, showing Verified OK for matched private/public keys tstpri.pem/ tstpub.pem Verification Failure for unmatched keys altpri.pem/ tstpub.pem. If the check is OK, then private and public key match (or the signature scheme is broken). One method works with any signature scheme and any program including OpenSSL: make a signature of a file with the private key, and check signature and file against the public key.
0 Comments
Leave a Reply. |