I am trying to verify a random certificate with OpenSSL in Windows. I've installed Win32 OpenSSL, but how do I verify a random certificate with the OpenSSL commandline? I know there are other ways, but I want to use the OpenSSL commandline :)

Thanks for you help!

EDIT: When I use openssl verify cacert.pem it gives me this error: enter image description here

New error: enter image description here


The first error was due to your trying to 'read' (and verify) a non-existent file.

The second would seem to not be an error, but a 'proper' failure to verify.

What the message actually says it that it cannot find the CA that issued the cert you are testing, and so cannot validate the chain (which would generally be, at minimum issuing CA > your cert).

The SSLeay demo server line in your second output would tend to indicate one reason for this is that indeed, you just generated a new CA.

It also looks like you are trying to validate your own CA cert, which is a little redundant - but if you really want to do that, you should run:

openssl verify -CAfile cacert.pem cacert.pem

A more useful/practical example would be validating a (hopefully) known-good cert. Not sure if you can pipe on Windows, but on Linux, you could do:

openssl s_client -connect google.com:443 </dev/null | openssl verify

If you want to see the cert, you can run:

openssl s_client -connect google.com:443 </dev/null | openssl x509 -text

I think you might want to spend a bit of time reading up on how PKI works: generally, a PKI is built when a 'trusted' entity (a Certificate Authority) issues a certificate for another entity - it basically vouches for that other entity (which can be an organisation, a server, a user, etc) being who it claims to be.

So validating/verifying a cert involves the following (grossly simplified explanation coming up):

  • from your end-user cert (i.e. the cert used on the domain you are checking - user here is whatever is making use of the cert, not necessarily a human), the Issuer is checked, and the Issuer's public key is also extract (for comparison against known keys for that issuer).
  • you could then check first that your end-user cert is properly signed (i.e. the signature contained in the cert is signed by the private key linked to the Issuer's public key, which is included in the cert)
  • you could then validate the Issuer's cert, either by checking a list of known-good certs (which is what the OS cert store does), or by repeating the previous two steps if the Issuer has been issued its cert by some other entity.

At some point, you end up at a self-signed cert belonging to an entity such as Verisign/LetsEncrypt/YourCAHere, which is the root of the chain of trust the PKI reflects.

| improve this answer | |

Couple of minutes ago another related post appeared on this site. The author linked this page which makes me believe that you should check

openssl verify
| improve this answer | |
  • I've seen that, but how should I know what -CAfile, cacert.pem & server.crt are? I mean where can I find the names? – hudhud Sep 30 '16 at 19:58
  • As the answer to the post says: server.crt is the certificate you want to verify and cacert.pem is the root CA certificate that has issued the certificate. – kaidentity Sep 30 '16 at 20:05
  • Ok, I want to try with this certificate: ComSignCA.crt and the root is ComSign when I write this information I it says that it cannot open the input file ComSign.pem. No such file – hudhud Sep 30 '16 at 20:12

openssl verify -CAfile ca-bundle.crt certificate.crt


openssl verify -CApath cadirectory certificate.crt

To verify a certificate, you need the chain, going back to a Root Certificate Authority, of the certificate authorities that signed it. If it is a server certificate on the public internet, that is likely (but not necessarily) one of the hundredish Root CAs that are trusted by the browsers. Those Root CA's public keys are shipped with every browser (in the equivalent of the ca directory in the second openssl command). Ultimately, each user of root certificates needs to decide what authorities they will trust - for browsers, that decision is made by the browser manufacturers and is a Big Deal (tm). You can find the root CAs each trusts - and use that in your root ca directory - if you want, or choose your own.

| improve this answer | |
  • I think the key here is that you can't ABSOLUTELY verify a certificate - you can only verify it against something. You decide what the something is - a homegrown certificate authority? The consensus root CAs that Google and Microsoft and Mozilla trust? That list minus some in countries you don't approve of? It is up to you... – crovers Sep 30 '16 at 19:51
  • Could you please provide an example? The CAfile, do I have to change that, the ca-bundle.crt and certificate.crt? Where do I find these information? – hudhud Sep 30 '16 at 19:53
  • Basically, each Certificate Authority (CA) has a public key (which they share) and a private key (which they do not). These CAs can be public ones (Thawte, Comodo, to name just a few) or private ones (set up by an individual or a company for internal use). The consumers of the certificates decide which CAs they will trust - in the case of the public web, that choosing is done by the browser manufacturers - they ship a list of CA public keys with their browsers. You could use those lists, if you choose to do so. Or you could make your own list. Or you could only trust your own Root CA. – crovers Sep 30 '16 at 20:16
  • Of course, if you only trust your own Root CA (or if you make your own list of public CAs), you will not be able to verify as valid certificates not part of your list. You can find extracted Root CA lists from browsers by googling, or look at wiki.mozilla.org/CA:IncludedCAs - the PEMs mentioned are all the public keys. If you extract all those public keys to a directory and use CApath as above, you will trust the same ones as Mozilla. Note it isn't a static list - the manufacturers trust additional CAs (and occasionally untrust CAs) from time to time. – crovers Sep 30 '16 at 20:19
  • certificate.crt is a file that contains the certificate - if you want to download that from an external website, you can use : openssl s_client -connect {HOSTNAME}:{PORT} -showcerts – crovers Sep 30 '16 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.