Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Our partner program is designed with flexibility in mind for partners who are at various stages of their business lifecycle. With financial investment and dedicated resources, you will continue to grow with TuxCare.
Would you like to work with a leader in open source and Linux security that values innovation and partnerships?
Partners receive benefits that are designed to reward the commitment that they have made to the sale of our products and services.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
Follow Us on Social
The expiration of a root certificate in the Let’s Encrypt certification chain causes multiple issues, especially when coupled with older versions of OpenSSL like those in CentOS 7.
OpenSSL behaviour in that version would fail validation if it found a “bad” (read: expired) certificate anywhere along the certification path. This has a ripple effect, making the connections to KernelCare’s servers fail. Users of live patching services like KernelCare (any version) on CentOS 7 are encouraged to update the ca-certificates package, which removes the affected certificate and thus allows the live patching client to resume working as normal.
The root certificate that expired in the Let’s Encrypt certification chain (DST Root CA X3) will remain in the chain until 2024. Recent versions of OpenSSL correctly ignore the expired certificate and validate using the alternate certificates present in the chain, but older versions of OpenSSL will fail the verification. This causes serious issues; TLS connections will fail when they should not. In an unfortunate twist of fate, the “certbot” utility itself will fail to update the chain and renew the Let’s Encrypt certificates (which would resolve the issue).
In CentOS 7, there is already an updated ca-certificates package that addresses the issue by removing the expired certificate, which then causes OpenSSL to no longer fail the validation of KernelCare servers’ certificates. If you have systems running CentOS 7, you should update this package as soon as possible to fix any issues related to failed connections. Note that this affects many other software packages and is not just a KernelCare specific issue, so updating ca-certificates is highly recommended in any scenario.
Updating the ca-certificate is done with the following command:
yum update -y ca-certificates
If you still have problems with systems being unable to reach our servers after updating ca-certificates, reach out to our support here.
If you would like to address this issue in an alternative way, you could blacklist the certificate manually. However, you do not need to do this if you update the ca-certificates package.
The following commands blacklist the expired certificate:
cp -i /etc/pki/tls/certs/ca-bundle.crt ~/ca-bundle.crt-backup
trust dump –filter “pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10” | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust extract
TALK TO A CYBERSECURITY EXPERT
Stay updated with the latest news and announcements from TuxCare.com
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...
In a symphony orchestra, instruments harmonize to create one pleasing...
We are pleased to announce that a new updated ePortal version...
We are pleased to announce that a new updated KernelCare agent...