RHEL/CentOS 6 OpenSSL client compatibility after DST Root CA X3 expiration

Thanks for the help folks, I still get a curious error when trying to update/install the rpm (existing latest openssl in centos 6 is 1.0.1e)...

error: Failed dependencies:
openssl-devel = 1.0.1e-58.el6_10 is needed by (installed) openssl-static-1.0.1e-58.el6_10.x86_64

However, yum install openssl-devel
Package openssl-devel-1.0.1e-58.el6_10.x86_64 already installed and latest version

EDIT think I fixed it by including the static and source file rpms as well at the same time.
Thanks for all the help.

1 Like

You won't need to install the source RPM, but that message indicates that your existing version of openssl-static doesn't like that you are upgrading openssl-devel and trying to leave it back on the old version, so the correct fix is just to install openssl-static in the same command like you did!

2 Likes

Those work nicely for me, thank you!

3 Likes

@ Osiris - thx - it's working like a charm with the manually compiled RPMs! :wink:

For the sake of completeness, here again the complete workflow to solve the DST Root CA X3 expiration problem with Centos / RHEL 6 ...

yum install wget
yum install krb5-devel zlib-devel lksctp-tools-devel util-linux make gcc rpm-build
curl -o openssl-1.0.2k-21.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/openssl-1.0.2k-21.el7_9.src.rpm
rpm -i openssl-1.0.2k-21.el7_9.src.rpm
cd ~/rpmbuild/SOURCES/
sed -i 's/secure_getenv(/getenv(/g' *patch
cd ../SPECS/
sed -i 's/%patch68 -p1 -b .secure-getenv/#%patch68 -p1 -b .secure-getenv/g' openssl.spec
rpmbuild -bb openssl.spec
cd ../RPMS/x86_64
rpm -U openssl-libs-1.0.2k-21.el6.x86_64.rpm openssl-1.0.2k-21.el6.x86_64.rpm

I also compiled a current ca-certificates so one doesn't need to manually remove the X3 Cert ...

How to build the ca-certificates RPM:

yum install asciidoc java-1.6.0-openjdk
mkdir -p /dl/ca-cert; cd /dl/ca-cert;
curl -o ca-certificates-2020.2.41-65.1.el6_10.src.rpm https://vault.centos.org/6.10/updates/Source/SPackages/ca-certificates-2020.2.41-65.1.el6_10.src.rpm
rpm -i ca-certificates-2020.2.41-65.1.el6_10.src.rpm
curl -o ca-certificates-2021.2.50-72.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/ca-certificates-2021.2.50-72.el7_9.src.rpm
rpm2cpio ca-certificates-2021.2.50-72.el7_9.src.rpm | cpio -idmv
cp certdata.txt ~/rpmbuild/SOURCES/
sed -i 's/Version: 2020.2.41/Version: 2021.2.50/g' ~/rpmbuild/SPECS/ca-certificates.spec
cd ~/rpmbuild/SPECS
rpmbuild -bb ca-certificates.spec
cd /root/rpmbuild/RPMS/noarch/
rpm -U ca-certificates-2021.2.50-65.1.el6.noarch.rpm

If someone is interested I could also publish the RPMs ... (I personally wouldn't install any RPMs from "foreign sources" on my servers ... ^^)

thx, bye from Austria
Andreas Schnederle-Wagner

8 Likes

For all interested parties. I've modified openssl.spec to incorporate shared files back into monolitic RPM file to match EL6 package contents.
URL for corresponding binary and source packages (openssl and ca-certificates) + openssl.spec is
https://server-support.co/openssl-el6/

3 Likes

I have problem with manually compiled RPMs on centos 6.

# rpm -U openssl-libs-1.0.2k-21.el6.x86_64.rpm openssl-1.0.2k-21.el6.x86_64.rpm
error: Failed dependencies:
openssl = 1.0.1e-58.el6_10 is needed by (installed) openssl-devel-1.0.1e-58.el6_10.x86_64
openssl = 1.0.1e-58.el6_10 is needed by (installed) openssl-perl-1.0.1e-58.el6_10.x86_64

How i can solve it? I have installed openssl-devel and openssl-perl x86_64.

1 Like

add the devel and perl RPM to the "rpm -U" call ... they are all there ... :wink:

5 Likes

Thank you very much for the summation @futureweb!

For openssl update needed to remove a python-libs-2.6.6-68.el6_10.i686 package from 6.10 @updates repo, as it had a fixed dependency that prevented the openssl install. It removed cleanly though, nothing using it apparently.

yum remove python-libs-2.6.6-68.el6_10.i686

due to:

error: Failed dependencies:
        libcrypto.so.10 is needed by (installed) python-libs-2.6.6-68.el6_10.i686
        libcrypto.so.10(libcrypto.so.10) is needed by (installed) python-libs-2.6.6-68.el6_10.i686
        libssl.so.10 is needed by (installed) python-libs-2.6.6-68.el6_10.i686
        libssl.so.10(libssl.so.10) is needed by (installed) python-libs-2.6.6-68.el6_10.i686

For the certificates update, I needed following changes:

  1. Add "-p": mkdir -p /dl/ca-cert; cd /dl/ca-cert;
  2. Add "cd ~/rpmbuild/SPECS" before "rpmbuild -bb ca-certificates.spec"
3 Likes

Signed up just to say thanks. The comments in this thread are pure gold. @futureweb incorporated the comments from many in this thread into a perfect post on building the openssl & ca-certificate packages in post #73. I happened to load these into Spacewalk, and yum is smart enough to install the openssl-libs on upgrade of openssl.

Thanks!

5 Likes

Hi @yaylife and welcome to the LE community forum :slight_smile:

I can't think of a better compliment :+1:

2 Likes

Your work is greatly appreciated Andreas

3 Likes

Wow, this openssl mailing list post has a much simpler solution for CentOS 6 / openssl < 1.0.2

Since openssl apparantly doesn't check the self-signature on root CA's, you can simply alter the expiration date of DST Root CA X3, and it will be trusted again. The following command fudges the expiration date to 30 September 2024 (the end-date of the ISRG Root X1 cross-signature) directly in the PEM-encoded certificate:

sudo sed -i s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/ /etc/pki/tls/certs/ca-bundle.crt

This works :cowboy_hat_face: no openssl upgrade needed!

6 Likes

This trades one problem for another... but maybe this one is less problematic (for some):

1 Like

At least this is not problematic for OpenSSL, which ignores the (now broken) self-signature.
Other applications & libraries should be able to anchor any LE chain to ISRG Root X1 directly, ignoring DST Root CA X3 completely (either because it's expired or corrupted), this was an OpenSSL-specific issue.

4 Likes

if it doen'st care about self-sign then would it need to keep same issuer? not sure intermediate from unknown issuer in trust store would work though

1 Like

I'm pretty sure users using this hack will know of the altered state. And as it's a client thing and not a server thing, it wouldn't influence anything else but the user when inspecting the altered certificate. Sooooo, this doesn't really matter.

3 Likes

haha nice hack - I should have visited more often!

2 Likes

Hello and thank you very much for this thread - I've been looking for a solution to this problem for some time! :slight_smile:

4 Likes

This worked perfectly, thank you for the instructions!

Can anyone advise how to get php-fpm to use the new openssl version (openssl-1.0.2k), instead of the old one (1.0.1e)?

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.