# OpenSSL 1.0.2u problems Let's Encrypt



## bagas (Sep 27, 2021)

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 (Sep 27, 2021)

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


----------



## bagas (Sep 27, 2021)

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 (Sep 27, 2021)

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 (Sep 29, 2021)

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 (Oct 3, 2021)

SirDice said:


> 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, 


richardtoohey2 said:


> the ports infrastructure will complain after 11.4 EOL anyway.


I agree with richardtoohey2 's assessment.


bagas said:


> 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


----------



## obsigna (Oct 3, 2021)

bagas said:


> 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.


I read the same, however, my impression is, that this is mainly an issue of old client software. Read again what you wrote yourself "_... old software will have problems *opening sites* using the Let's Encrypt certificate."_ You servers don't open sites, do they?

IMHO, this would be an issue for your servers only, if these provide certificate based client authentication for clients sending in their's LE certificates (I even don't know if this is possible with LE). In case your servers don't need to validate foreign certificates, force update your own LE certificates and you should be fine.

I may be wrong, though, and in that case I would be happy to learn otherwise.


----------



## reddy (Oct 19, 2021)

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?


----------

