Not possible.
Something is wrong with your system (I just haven't figured out where... yet).
Provided the -CAfile [both /etc/ssl/certs/ca-bundle.crt and /var/tmp/isrgrootx1.pem] OpenSSL returns "three '1's" [perfect score].
But when no -CAfile is given, it fails, with:
error 20 at 0 depth lookup: unable to get local issuer certificate
This is clearly a setting within OpenSSL.
Which may have something to do with where it defaults -CAfile location and what is found there.
I re-tried to create my Keystore by verifying with the chain.pem rather than the cert.pem. Then, I added the chain to the root in order to produce the keystore output.
openssl verify -CAfile /usr/tmp/isrgrootx1.pem chain.pem
cat chain.pem /usr/tmp/isrgrootx1.pem > allcacerts.crt
openssl pkcs12 -export -chain -CAfile allcacerts.crt -in cert.pem -inkey privkey.pem -out my_apps.keystore -name tomcat
I re-deployed my Apache Tomcat and the new Keystore WORKED!!
But, I also don't understand what is wrong with my system setup -- the original problem began on October 1 (after DST Root X3 expired) on our Centos6 servers running openssl 1.0.1 and 1.0.2. I've been trying to get this new Centos7 environment working in order to migrate our production environments before our current certs & keystores expire in 8 days!!
For a production environment, where should isrgrootx1.pem be located?
NOTE: When I performed the above commands (openssl, cat, openssl) using /etc/ssl/certs/ca-bundle.crt I was unable to create the keystore:
Error unable to get issuer certificate getting chain.
That problem could have been related to what is described here.
Your post #21 shows your Centos 7 system using openssl 1.1.1 although I thought the base package was still 1.0.2k on Centos7 too. How did you update that? I know EPEL7 has openssl 1.1.1 in it but installed from that it is named openssl11. At least that's how I understand it based on my use of RHEL7 and this stackoverflow post for Centos7.
I wondered about your openssl version as you were not using -servername for your s_client commands. Without that and openssl 1.0.2 your server responds with a self-signed cert which cannot verify (of course). The same can be seen with openssl 1.1.1 using -noservername with s_client.
On our Centos6 machines, I upgraded to openssl 1.0.2 per the openssl blog post: Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog
But, that did not solve my problem, and after many trials, I figured it was time to spin up a Centos7, thinking this would fix everything (as Centos6 EOL is the end of this year).
On the newly spun up Centos7, the default openssl was 1.0.2. I continued to have the openssl failure. So I upgraded to 1.1.1k hoping this would solve my problem. I also updated ca-certificates and installed certbot using pip and not snap (my host provider recommended against using snap on a VPS).
Out of fear, I installed openssl at /usr/local/openssl rather than overwrite the existing ssl installation directories -- some research showed that legacy packages still require 1.0.2. Then I discovered that the certs folder was empty at /usr/local/openssl so I then created a symbolic link to /etc/ssl/certs:
[root@www conf]# ls -la /usr/local/ssl/certs
lrwxrwxrwx 1 root root 14 Dec 21 01:24 /usr/local/ssl/certs -> /etc/ssl/certs
On CentOS6 running 1.0.2:
openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
openssl version -d
OPENSSLDIR: "/etc/pki/tls"
On CentOS7, running 1.1.1:
openssl version
OpenSSL 1.1.1k 25 Mar 2021
openssl version -d
OPENSSLDIR: "/usr/local/ssl"
My notes show that I used these instructions to install openssl 1.1.1:
Well, taking a step back from sorting your system configuration, is the only problem you are having the failing openssl verify command?
If so, I think you just need a new format for the command. This thread addresses the change required. If I have lost the plot (as they say), please explain.
As an aside, I would avoid using non-standard methods of installing key system components like openssl. As I noted earlier, openssl 1.1.1 is available in EPEL7 as a supported package component. All that is needed is to change the name in any command to openssl11. The link I provided to stackoverflow was for a post by the openssl package maintainer for EPEL7 who further linked to key info about RHEL/Centos. It isn't some random person doing something with unknown goals and implications.
That said, the openssl verify examples shown in the thread I linked to in this post work for me with both openssl 1.0.2k and 1.1.1. Both on an RHEL system with the v1.1.1 coming from EPEL7.
I am very grateful to have a workaround until I can try the install again - especially with the holidays upon us. So, thank you both very much for helping me.
Yes, the only problem I have had since October is with the "openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt chain.pem" that I was using to verify the cerificate & chain prior to combining to create the keystore.
OK, to recap, when I install EPEL7 properly, I can use either openssl verify (1.0.2) or openssl11 verify (1.1.1) and reference the location of CAfile isrgrootx1.pem?
Or, does the EPEL7 not require that I download isrgrootx1.pem at all? This is where I get lost.
In a production environment, do you recommend I download isrgrootx1.pem to a folder in /etc/pki -- or do you recommend that I continue to use /usr/tmp or /opt/ssl?
Gracias,
Nacho
I just used the first example command from this post in that thread:
So, this command:
openssl verify -purpose sslserver -untrusted chain.pem cert.pem
That command works with the openssl version 1.0.2 from the standard Centos7 package. You do not need to install a different version.
That does not use the -CAfile option. The "stock" openssl defaults to your CA system store. Your Centos7 CA store has ISRG Root X1 in it already. You should be fine.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.