Now when I run the following command to verify, getting error:
[root]# openssl verify -CAfile 2-inter.crt 1-server.crt
1-server.crt: C = US, O = Let's Encrypt, CN = R3
error 2 at 1 depth lookup:unable to get issuer certificate
My web server showing error as well when using the cert:
Missing CA: /O=Digital Signature Trust Co./CN=DST Root CA X3 (2e5ac55d).
Error: Unable to verify certificate chain.
Error: Unable to validate web_service_certificate
Any idea why the chain validation is broken?
Note: When I use a self-signed certificate chain (Root-Inter-leaf) everything works fine (I just need to add the root to the trust store, that's why I am trying to use Let's encrypt, however, it's failing.
The error Unable to validate web_service_certificate is from the web server software itself.
I tried the verify command from the link you shared, between root and intermediate + intermediate + server and I got:
I noticed when checking the command on my Macbook, and it shows it's okay
# openssl verify -untrusted 3-root.crt 2-inter.crt
2-inter.crt: OK
# openssl verify -untrusted 2-inter.crt 1-server.crt
1-server.crt: OK
But on the CentOS 7 machine,
# openssl verify -untrusted 3-root.crt 2-inter.crt
2-inter.crt: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 1 depth lookup:unable to get issuer certificate
# openssl verify -untrusted 2-inter.crt 1-server.crt
1-server.crt: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup:unable to get issuer certificate
Anything else I should check to verify the certificate is valid on a CentOS 7 machine and it's able to validate the chain?
I don't know why the server would verify the cert. Usually the server just sends out the cert and the client verifies that it is trusted in their CA store. A server can't possibly know whether a client will trust the certs.
Setting that aside, the verify error sounds like your CA root store does not have the ISRG Root X1 cert in it. You could try updating that with
# openssl verify -untrusted 2-inter.crt -CAfile /etc/ssl/certs/ca-bundle.crt 1-server.crt
1-server.crt: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup:unable to get issuer certificate
I don't understand how that can be. You found the ISRG root in that CA store with your awk command a few posts back. Are you sure those files 2-inter.crt and 1-server.crt are the chain.pem and cert.pem, respectively, created by certbot?
As evidence this is what I get I have the same CA cert store version as you.
openssl verify -untrusted chain.pem -CAfile /etc/ssl/certs/ca-bundle.crt cert.pem
cert.pem: OK
OpenSSL and similar programs are not very intuitive to start with, and behavior of some commands has changed across releases. Some versions will accept a combined chain for -untrusted, others require multiple arguments for single certificates. E.g.:
Just for fun I looked at the openssl changelog and it says -untrusted support for a set of certs was done at the same time as -purpose was introduced (between 0.94 and 0.95). The current docs say the -untrusted file can have one or more certs and be set multiple times.
Two new options to the verify program: -untrusted allows a set of untrusted certificates to be passed in and -purpose which sets the intended purpose of the certificate. If a purpose is set then the new chain verify code is used to check extension consistency.
# openssl verify -purpose sslserver -untrusted fullchain.crt 1-server.crt
1-server.crt: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup:unable to get issuer certificate
# openssl verify -purpose sslserver -untrusted 3-root.crt -untrusted 2-inter.crt 1-server.crt
1-server.crt: C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup:unable to get issuer certificate
Just to confirm
1-server.crt = Is just the actual certificate ( ====Common Name=illumio.consulting)
2-inter.crt = Is the intermediate cert (Let's encrypt ====Common Name=R3)
3-root.crt = Is the root cert ( ====Common Name=ISRG Root X1)
fullchain.crt is the regular bundle that has all three the above in one file
I don't have the ability to spin up legacy OS builds right now, but I am fairly certain I had issues with -untrusted on some .98 and 1.02 versions; I don't remember the minor/letter version. Looking at my notes, it appears to have been when I was running OSX 10.10 and 10.11 and using the stock OpenSSL. (I did not write which OpenSSL version was affected in my notes)
I only started using -purpose sslserver recently, thanks to someone posting about it here!
Can you upload the contents of that file (or show it)? The current default LE chain would have 2 certs in the intermediate chain. As long as there is no string in it saying "PRIVATE" it is ok to post.
The root is used by clients to validate that the leaf and intermediates they received chain to something they trust. Where did you get that? It is not sent out by the server - each client already has ones that they trust.
And, just for clarity ... I am using an AWS Linux2 test server which is a close cousin of your CentOS 7. I have the same major version of openssl as you as well as cert store. openssl gets security backports but not features so what works on my test system should be working on yours.
Thanks. That "root" is not really a CA root. Your inter and root files are the two parts of the default "long intermediate" chain returned by Let's Encrypt. At least I am no longer confused by that name
Good news is your server (leaf) cert with that inter verifies fine on my system.
We should check if you have something odd in your CA store. What does this show:
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.71.1.el7.x86_64
# openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
I ran the previous commands as well from @jvanasco
# openssl verify -purpose sslserver -untrusted fullchain.pem cert.pem
cert.pem: OK
# openssl verify -purpose sslserver -untrusted chain.pem cert.pem
cert.pem: OK
# openssl verify -purpose sslserver -untrusted fullchain.pem chain.pem cert.pem
chain.pem: OK
cert.pem: OK
I think we are making some good progress as there was something wrong with the CentOS 7. I still working on the setup and will test soon with the web server itself.
I have the same CA cert store version as you.