Use the openssl verify command to verify a certificate chain, certificate, CRL, and matching key pairs. If you work with TLS certificates, private keys, intermediate certificates, and trust chains, understanding how to use OpenSSL to verify certificates is one of the most useful troubleshooting skills you can have.
In practical terms, openssl verify helps answer questions like these: Does this certificate chain correctly to a trusted root? Is the intermediate missing? Has the certificate been revoked? Does this certificate match the private key I think it matches? This article walks through each of those common scenarios with examples.
After it is all said and done, the examples in this article should have you well on your way to using OpenSSL to verify a certificate chain, certificate, CRL, self-signed certificate, and matching key pairs.
If you need to retrieve a certificate chain from a live server first, see our guide on openssl_s_client. If you need to inspect a certificate in more detail, our openssl x509 article is also a helpful companion.
Table of contents
- openssl verify certificate chain
- openssl verify certificate and CRL
- openssl verify certificate and key
- OpenSSL verify self signed certificate
- Java verify certificate
- Common openssl verify errors
- Frequently asked questions
openssl verify certificate chain
To verify a certificate and its chain for a given website with OpenSSL, run the following command:
openssl verify -CAfile chain.pem www.example.org.pemWhere -CAfile chain.pem is the downloaded certificate chain installed at the site and www.example.org.pem is the downloaded end entity server cert. You can download the certificate chain by visiting the website and using your browser tools to export the chain. Alternatively, you can use the examples at openssl_s_client to get the chain from the command line.
This is one of the most common openssl verify use cases. You are telling OpenSSL to trust the certificates contained in chain.pem and then validate the leaf certificate against that trust material. If the chain is complete and correctly ordered, OpenSSL should return an OK result.
You can also add the -x509_strict flag for strict compliance.
Strict mode can be useful when you want OpenSSL to enforce tighter X.509 certificate requirements during validation. In environments where certificate profiles matter, or where you are troubleshooting an unusual validation failure, this extra strictness can help reveal issues that a more relaxed check might ignore.
To verify the intermediates and root separately, use the -untrusted flag. Note that -untrusted can be used once for a certificate chain bundle of intermediates, or can be used more than once for each intermediate in a separate file.
openssl verify -CAfile root.pem -untrusted intermediate.pem www.example.org.pemThis is a useful pattern when you want to distinguish between the trusted root CA and the intermediate CA certificates presented by the server. In other words, the root is your trust anchor, and the intermediate helps build the certification path from the leaf certificate to that root.
Add the -show_chain flag to output the certificate chain and corresponding depth of each certificate in the chain.
openssl verify -show_chain -CAfile chain.pem www.example.org.pemThe -show_chain flag is helpful because it lets you see how OpenSSL built the path. When you are troubleshooting an incomplete chain or the wrong intermediate, seeing the chain depth output often makes the problem much easier to spot.
What openssl verify is checking in a certificate chain
When you run openssl verify against a certificate chain, OpenSSL is evaluating several things at once:
- whether the issuer of the leaf certificate is present in the chain
- whether the signatures between certificates are valid
- whether the chain can be built to a trusted root
- whether the certificates are within their validity period
- whether revocation checks are being enforced, if you use CRL-related options
This is why the command is so useful for troubleshooting. It does more than just inspect a single certificate file. It evaluates the trust path.
openssl verify certificate and CRL
To verify a certificate with its CRL, download the certificate and get its CRL Distribution Point. The following commands demonstrate how to use OpenSSL to check a certificate against its CRL.
openssl x509 -noout -text -in www.example.org.pem | grep -A 4 'X509v3 CRL Distribution Points'In the output you should see the CRL URL.
A CRL, or certificate revocation list, is published by a CA to identify certificates that have been revoked before expiration. If you are validating a certificate for a more security-sensitive workflow, checking revocation status can be an important step.
Next, download the CRL with the wget function. It will be in DER format, so we will be converting it to PEM format for the openssl verify function to work.
wget -O crl.der http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1.crlNext, convert the CRL to PEM format with the openssl crl function:
openssl crl -inform DER -in crl.der -outform PEM -out crl.pemNext, concatenate the chain and the CRL into one file:
cat chain.pem crl.pem > crl_chain.pemFinally, use OpenSSL to verify the SSL certificate with its CRL:
openssl verify -crl_check -CAfile crl_chain.pem www.example.org.pemYou should see an OK message. If the certificate has been revoked, you will see a lookup:certificate revoked message.
This is a great example of why openssl verify is more than a basic certificate syntax check. With the right flags and supporting files, it can be part of a more complete certificate validation workflow.
When CRL checking is useful
CRL checking is especially useful when you need to answer questions like these:
- Has this certificate been revoked by the issuing CA?
- Am I validating a chain for a security-sensitive internal workflow?
- Do I need an offline method of verifying revocation data?
Depending on the environment, OCSP may also be part of certificate status checking, but for this article the CRL-based method provides a practical OpenSSL example you can run from the command line.
openssl verify certificate and key
Question: How do I verify that a private key matches a certificate? The answer is to make use of the -modulus option in the openssl rsa and openssl x509 commands.
Technically, this part uses related OpenSSL commands rather than the openssl verify command itself, but it is one of the most common follow-up checks people need when validating certificates. In practice, many administrators searching for openssl verify also need to verify that the certificate and private key belong together.
To verify a certificate and key match we will use 2 different steps.
- Verify that the private key has not been corrupted or tampered with.
- Verify that the modulus of the private and public key in the certificate match.
To use OpenSSL to verify an SSL certificate is the matching certificate for a private key, we will need to break away from using the openssl verify command and switch to checking the modulus of each key. This example demonstrates the OpenSSL command to check a certificate with its private key.
First, use the openssl rsa command to check that the private key is valid:
openssl rsa -check -noout -in key.pem
The result should be: RSA key ok. If not, you will need to determine why your key may be corrupt.
After verifying that the private key is valid, determine its modulus with this command:
openssl rsa -modulus -noout -in key.pem | openssl sha256
Then also determine the modulus of the public key, running the same command except with the openssl x509 command instead of rsa.
openssl x509 -modulus -noout -in cert.pem | openssl sha256
Verify that the modulus of both the public key and private key are the same. If they are, then you have a matching public key and certificate with your private key. If they are not the same then you are not using the correct private key. At this point you should consider rekeying and renewing your certificate.
This modulus comparison is a common troubleshooting technique when a web server refuses to start after a certificate replacement, or when a certificate deployment appears correct but TLS still fails because the wrong private key was attached.
Additionally, you can verify that the modulus of the key in the CSR is also the same by running the following command against the CSR:
openssl req -noout -modulus -in example.csr | openssl sha256You now have confidence that you have a matching key pair across your certificate, key, and CSR by having learned how to use OpenSSL to verify your certificate and key using the -modulus option in the rsa and x509 utilities.
What to do if the key and certificate do not match
If the modulus hashes do not match, that usually means one of these things is true:
- the wrong private key is being used
- the certificate was issued from a different CSR
- files were mixed up during deployment
- the key or certificate file was replaced by mistake
When that happens, the safest path is usually to locate the correct key pair or rekey and reissue the certificate.
OpenSSL verify self signed certificate
To verify a self signed certificate with OpenSSL, use the same steps as in the previous section. After confirming the hashes match, verify the self signed certificate against itself with this command.
openssl verify -CAfile selfsigned.crt selfsigned.crtThe self signed certificate is verified against itself because as the name suggests, it signed itself.
Note that if the certificate is expired or not yet valid, the verification will fail.
This is a useful lab and internal PKI technique when you are working with a self-signed certificate for testing, but remember that successful verification here does not mean the certificate is broadly trusted by browsers or operating systems. It only means the certificate successfully validates against the trust material you supplied.
Java verify certificate
You may find it useful to programmatically verify a certificate, a certificate chain, or a certificate path with Java. For this, you can use the Java security package.
Here is a Java code sample for verifying a certificate chain with Java security. For the complete example with the ability to build a jar artifact to run locally for the certificate validation, view the GitHub repository.
public static boolean validateCertificateChain(final List<X509Certificate> certificates) {
for (int i = 0; i < certificates.size(); i++) {
try {
if (i == certificates.size() - 1) {
if (isSelfSigned(certificates.get(i))) {
certificates.get(i).verify(certificates.get(i).getPublicKey());
}
} else {
certificates.get(i).verify(certificates.get(i + 1).getPublicKey());
}
} catch (Exception e) {
return false;
}
}
return true;
}To follow along in this piece of code:
- pass in an ordered list of certificates as a parameter, starting from the leaf and ending with the root, to be validated.
- Loop through the list of certificates.
- If the certificate is the last in the list, check if it is self-signed. If it is not self signed, do nothing and stop validation (this will pass even though it’s an incomplete chain). If it is, verify the signature of the certificate with its own public key.
- If the certificate was not last in the list, verify the signature of the certificate with the public key of the next certificate in the list.
- If at any point verification fails an exception will be caught and the method will return false. Else, the method will return true.
This example is helpful for understanding the logic of certificate path validation, but it is also worth remembering that production-grade certificate validation often involves more than signature checking alone. Things like trust anchors, expiration, revocation, and policy handling can also matter depending on the use case.
To verify a certificate path these steps can be followed programmatically with code or by hand using the OpenSSL commands above.
When Java-based certificate verification is useful
You may want Java-based verification when you are:
- building an internal certificate validation tool
- testing a certificate chain inside a Java application
- validating certificates before import into a Java keystore
- troubleshooting trust issues in a Java-based service
Common openssl verify errors
Here are several common issues people run into when using openssl verify:
unable to get local issuer certificate
This usually means the intermediate or issuer certificate needed to build the chain is missing from the files you supplied.
self signed certificate in certificate chain
This often appears when the root CA is not trusted in the context you are using, or when a self-signed certificate appears where OpenSSL did not expect one.
certificate has expired
If the certificate or one of the CA certificates is outside its validity period, verification will fail even if the signatures and chain are otherwise correct.
certificate revoked
If you are checking against a CRL and the certificate appears there, OpenSSL will fail validation and report that the certificate was revoked.
These errors are exactly why openssl verify is such a valuable troubleshooting command. It gives you a precise clue about what part of the trust path or validation logic failed.
Related OpenSSL resources
Frequently asked questions
What does openssl verify do?
The openssl verify command validates a certificate against supplied trust material such as a CA bundle, intermediate certificate, or CRL. It is commonly used to check certificate chains and troubleshoot trust issues.
How do I verify a certificate chain with OpenSSL?
Use a command such as openssl verify -CAfile chain.pem cert.pem, where the CA file contains the trust chain and the certificate file contains the leaf certificate you want to validate.
Can openssl verify check revocation?
Yes. With CRL-related options such as -crl_check and the appropriate trust material, OpenSSL can verify whether a certificate appears on a certificate revocation list.
Can OpenSSL verify that a certificate matches a private key?
Not directly with the openssl verify command itself. That workflow is usually done by comparing the modulus of the private key, certificate, and optionally the CSR using openssl rsa, openssl x509, and openssl req.
How do I verify a self-signed certificate with OpenSSL?
You can verify a self-signed certificate against itself with a command such as openssl verify -CAfile selfsigned.crt selfsigned.crt, assuming the certificate is otherwise valid and within its validity period.
Conclusion
This article has provided examples with OpenSSL on how to verify a certificate, certificate chain, CRL, self-signed certificate, and matching key pairs. If you spend much time troubleshooting TLS, PKI, or certificate deployments, openssl verify is one of the most practical commands to have in your toolkit.
Let us know in the comments if you have any questions or would like to see more examples.
Leave a Reply