OpenSSL 1.0.2u problems Let's Encrypt

bagas

Well-Known Member

Reaction score: 9
Messages: 284

Hello.
I read the news that the old software will have problems opening sites using the Let's Encrypt certificate.
There are several servers running old FreeBSD 11.4-RELEASE-p13 software, it uses OpenSSL 1.0.2u-freebsd 20 Dec 2019, apache 24 web server.
What should be done in this case?
Upgrading the system is not an option.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,347
Messages: 38,863

FreeBSD 11.4 will be end-of-life in three days. So you really don't have any other option but to upgrade.
 
OP
bagas

bagas

Well-Known Member

Reaction score: 9
Messages: 284

Users of older distributions based on OpenSSL 1.0.2 are offered three workarounds to solve the problem:
Manually succeeded IdenTrust DST Root CA X3 root certificate and install the standalone (not cross-signed) ISRG Root X1 root certificate.

The "--trusted_first" option can be specified when running the openssl verify and s_client commands.

Use a server-side certificate signed with a standalone SRG Root X1 certificate that is not cross-signed. This method will lead to the loss of compatibility with old Android clients.

I don’t understand how to implement it?
 

richardtoohey2

Aspiring Daemon

Reaction score: 314
Messages: 634

Not sure it's much of a solution, but you could rebuild Apache against ports OpenSSL (1.1.1) - but that's probably not far off upgrading the whole system. And I think the deadline will be the same - the ports infrastructure will complain after 11.4 EOL anyway.

I can't guarantee this would work or improve anything - just talking aloud - if 1.0.2 is the problem then there's a path to 1.1.1 but not sure it's a good path!
 

jcmichot

New Member

Reaction score: 6
Messages: 5

For client side with old OpenSSL 1.0.2 or lower you probably just need to update /usr/local/openssl/cert.pem or /etc/cert.pem to get ISRG Root X1
 

astyle

Daemon

Reaction score: 482
Messages: 1,118

FreeBSD 11.4 will be end-of-life in three days. So you really don't have any other option but to upgrade.
One idea that I have is to use ports to get the latest version of OpenSSL, that one has been patched for Heartbleed. But,
the ports infrastructure will complain after 11.4 EOL anyway.
I agree with richardtoohey2 's assessment.
This method will lead to the loss of compatibility with old Android clients.
Most of the time, the problem is rather easily solved by removing the phone's connection entirely, and re-establish it anew, with the up-to-date parameters. Do it on the phone, not the server. Hope this helps :)
 

reddy

Active Member

Reaction score: 78
Messages: 120

Do we know when security/ca_root_nss will simply remove the expired certificate DST Root CA X3 from their bundle?

We're running FreeBSD 12.2 and are using a software stack being exposed to this bug in openssl which is also documented by the guys at TrueNas (because the technology we rely on maintains its own old fork of openssl). Basically, because of this bug in openssl if the expired certificate is present in the trust store, the expired cert is picked instead of the new one, which of course results in a TLS authentication failure. So apps cannot connect to websites and APIs using a let's encrypt certificate... (which represents many endpoints these days).

We're going to keep removing the cert manually for time being but this is not a sustainable solution I'm afraid, it'd be much better if upstream just removed it. How fast are expired certs usually removed from the bundle?
 
Top