I have three certificates in a chain:

  • root.pem
  • intermediate.pem
  • john.pem

When I examine them using openssl x509 -in [filename] -text -noout they look fine, root.pem looks like it is self-signed (Issuer == Subject), and the Subject of each certificate is the Issuer of the next one, as expected.

And indeed I can verify the chain up to the intermediate certificate:

$ openssl verify -CAfile root.pem root.pem
root.pem: OK
$ openssl verify -CAfile root.pem intermediate.pem
intermediate.pem: OK

However, john.pem fails:

$ openssl verify -CAfile root.pem -CAfile intermediate.pem john.pem
john.pem: C = CL, [...redacted data...]
error 2 at 1 depth lookup:unable to get issuer certificate

To the best of my knowledge, this means that openssl is unable to find the issuer for intermediate.pem. Which doesn't make sense since root.pem is indeed the issuer for intermediate.pem.

What am I missing?

Edit: I had originally posted an answer saying that root.pem and intermediate.pem should be concatenated in one file, and then one should use this file as the parameter for -CAfile. This is WRONG, because this implicitly trusts intermediate.pem, as Johannes Pille points out. Read the link he posted in my deleted answer: https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html

  • Please delete your answer, it is dangerous misinformation! – Johannes Pille Feb 14 '19 at 16:03
  • 1
    @JohannesPille Done, thank you for the information – Jong Bor Feb 15 '19 at 22:47
  • Kudos for actually doing it and the quick reaction. – Johannes Pille May 3 '19 at 23:40

You don't have to cat the two certificates together in order to verify them.

If you have the following three certificates:

  • root.pem - stores a self-signed certificate.
  • intermediate.pem - stores a certificate signed by root.pem
  • john.pem - stores a certificate signed by intermediate.pem

And you trust only root.pem, then you would verify john.pem with the following command:

openssl verify -CAfile root.pem -untrusted intermediate.pem john.pem

It you had many intermediates, you could just chain -untrusted intermediate2.pem -untrusted intermediate3.pem ...

| improve this answer | |
  • This. Is the only right answer. – Johannes Pille Feb 14 '19 at 16:04
  • I thought that if I had both the Intermediate and Root CA Certificates in the bundle openssl would pick those up and verify the certificates. Is there a reason this would be happening? Like, the person who signed the user certificate didn't sign it with the Intermediate but the root, or something? – FilBot3 Jun 28 '19 at 18:44
  • The last sentence of this answer is wrong. If you have many intermediates, you need to concatenate them into one intermediate file then use the untrusted flag once. Using the untrusted flag multiple times does not work. – AjaxLeung Jul 11 '19 at 16:59
  • 1
    @AjaxLeung - both multiple -untrusted options (in any order) or a single -untrusted option pointing to a bundle of intermediates (concatenated in any order) works. This is with OpenSSL version 1.1.1c on Ubuntu. – garethTheRed Jan 19 at 20:28
  • Yeah I was mistaken. I think I just wasn't using the right files at the time I wrote the comment. – AjaxLeung Jan 19 at 22:05

what @antiduh said only works for single intermediate certificate case for me. By adding more than one -untrusted intermediate.pem in the command seems not work. Not sure is it related to specific openssl version.

According to the openssl document: [https://linux.die.net/man/1/verify]

-untrusted file

A file of untrusted certificates. The file should contain multiple certificates

In my case I have a chain like: root.pem -> intermediate1.pem -> intermediate2.pem -> john.pem

by cat intermediate1.pem & intermediate2.pem into a single intermediate-chain.pem file and then run openssl verify -CAfile root.pem -untrusted intermediate-chain.pem john.pem works for me.

Also seems the in ca extension you need set basicConstraints = CA:true otherwise I still encounter openssl verify report error.

| improve this answer | |

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.