verify.1s

openssl verify [options] [cert.pem ...]

cert.pem ...
    One or more X.509 certificate files to be verified. These are typically in PEM format.

-CAfile file
    Specifies a file containing trusted CA certificates (e.g., root CAs) used to build and verify the certificate chain.

-CApath directory
    Specifies a directory containing trusted CA certificates. Certificates in this directory must be hashed using c_rehash or openssl rehash.

-untrusted file
    Specifies a file containing untrusted certificates that may be part of the chain but are not considered trusted root CAs.

-crl_check
    Enables verification against Certificate Revocation Lists (CRLs) to ensure certificates in the chain have not been revoked. Requires CRLs to be available in the trusted store.

-purpose purpose
    Checks if the certificate is valid for a specific purpose (e.g., sslclient, sslserver, email). This enforces extended key usage constraints.

-verbose
    Provides detailed output during the verification process, showing each step and reason for success or failure.

-depth num
    Sets the maximum verification depth, i.e., the maximum number of intermediate CA certificates that can be present in the chain.

-partial_chain
    Allows verification even if the full chain cannot be built up to a trusted root, verifying as much as possible.

-show_certs
    Displays the certificates in the chain found during verification, from the leaf certificate up to the trusted root.

The openssl verify command is a crucial utility within the OpenSSL toolkit, designed for the rigorous validation of X.509 certificates and Certificate Revocation Lists (CRLs). Its primary function is to ascertain the trustworthiness of a given digital certificate by meticulously building and verifying its chain of trust, tracing it back to a securely trusted root certificate authority. Beyond just chain validation, the command is also capable of checking CRLs, an essential step to ensure that none of the certificates within the chain have been revoked due to compromise or other issues.

This versatile tool performs an array of vital checks, including cryptographic signature verification, assessment of certificate expiry dates, validation of basic constraints (such as whether a certificate is a CA), examination of key usage extensions, and adherence to name constraints. Through these comprehensive checks, openssl verify serves as a foundational component for securing communications and authenticating entities across a multitude of network protocols and applications, including but not limited to HTTPS, VPNs, and secure email systems. Its diligent use ensures the integrity, authenticity, and non-repudiation of digital identities in the digital landscape.

Successful verification heavily relies on a properly configured trust store (-CAfile or -CApath) with up-to-date and valid trusted CA certificates. For effective revocation checking, CRLs must be current. The command is sensitive to certificate expiry dates and cryptographic integrity; any issues will lead to verification failure. A solid understanding of X.509 certificate concepts is crucial for interpreting the results.

The openssl verify command typically returns 0 upon successful verification of all certificates and a non-zero value if any certificate fails verification. This behavior is highly valuable for scripting and automated certificate validation processes.

While openssl verify can leverage system-wide default paths for trusted CAs (e.g., /etc/ssl/certs), it is often best practice to explicitly specify the trusted certificate store using -CAfile or -CApath for specific verification tasks, ensuring control over the trust anchors.

The openssl command suite, including openssl verify, is an integral part of the OpenSSL project, which originated in 1998 as a fork of the SSLeay library. It has continuously evolved, supporting new cryptographic standards, algorithms, and security features. openssl verify has been a fundamental component since early versions, undergoing regular updates to comply with evolving X.509 standards and to address new security challenges and vulnerabilities in certificate handling. Its persistent development highlights the ongoing necessity for robust cryptographic verification in the dynamic digital landscape.

openssl(1), x509(1SSL), crl(1SSL), genrsa(1SSL), req(1SSL)