Sudden OpenSSL Error messages: error:14090086 using file_get_contents

Question

I've searched for issues with this error but I'm baffled on what may have happened between a number of my own servers that have started to display this error:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in /var/www/html/file_get.php on line 7

Line 7 is the file_get_contents command.

These are (Debian) servers under my control so I know nothing has (to my knowledge) happened/changed or updated/upgraded.

I know I can use the solution of including the below, but I'm keen to understand what has happened first (plus I have many, many files I'd need to update). I also really need to understand which server is the one that has the potential issue.

I have 3 servers, all of which access another 4th server with file_get_contents requests. 2 of the servers have suddenly (today a few hours ago) started to fail with the above error, the third one seems to still work fine.

I suspect the issue is with the two servers that display the issue rather than the 4th one they are all trying to access.

If I implement this code, it works, but I'd rather find the root cause:

$arrContextOptions=array(
    "ssl"=>array(
        "verify_peer"=>false,
        "verify_peer_name"=>false,
    ),
);  

and modify the file_get_contents to the following:

file_get_contents($input, false, stream_context_create($arrContextOptions)));

But as mentioned, I have hundreds of files that would need changing.

All servers are Debian and use Lets Encrypt certs 9which are valid).

I have tried adding the following to the php.ini:

openssl.cafile=/etc/letsencrypt/live/myserver.com/cert.pem

But this has not worked (the same error remains).

The openssl version of the server taht still works is OpenSSL 1.1.0f 25 May 2017 (Library: OpenSSL 1.1.0l 10 Sep 2019), the two that display the error are OpenSSL 1.1.0l 10 Sep 2019 not sure if this is relevant.

Any help would be appreciated.

UPDATE

So I have been able to resolve this so far. After a lot of test and trial I'm honestly not quite sure what resolved the problem for sure to get it working again, but I did all of the below:

• apt upgrade
• apt update
• I removed the old certbot-auto
• Installed certbot (newer version)
• Removed mozilla/DST_Root_CA_X3.crt from /etc/ca-certificates.conf
• Ran update-ca-certificates

Again, not sure which of the above (or the combination of the above) resolved the problem, but it's working for me now.

Unchaste

One of the root certs that cross-signed LetsEncrypt expired today. Try updating your ca-certificates package, and if that doesn't work then you're probably on an EOL version of Debian and desperately need to upgrade. – Deterrence

@Deterrence ah thanks, good place to start, thank you. – Unchaste

See: openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire – Crenshaw

I've updated my question with what worked for me, hopefully it will help someone. Thanks to all who answered. – Unchaste

I think "!mozilla/DST_Root_CA_X3.crt" removing and update-ca-certificates is the solution. It helps me. See my comment on Gaurang answer. If you search in google for this error you find thousands of websites with error messages. – Homestead

Answer 1

The similar issue I was face with Ubuntu 16.04.7, In my case I was getting SSL Error: Certificate expired message while try GET / POST using Postman.

Here is the solution:

1. edit the /etc/ca-certificates.conf find the mozilla/DST_Root_CA_x3.crt
2. add ! sing at the start of the line i.e. !mozilla/DST_Root_CA_x3.crt
3. save your changes and then update the certificate sudo update-ca-certificates
4. reboot the server

Before The Solution

After The Solution

Zymometer

Thank you very much for this solution. Its works very well. After update-ca-certificates a reboot was not necessary to fix the errors. Why do we need a reboot? Millions of websites has this problem at the moment with file get contents and also with wget in sh. All my cronjobs has not worked anymore. For example a job to generate the ads.txt. I have already lost alot of money because of this problem. Thank you for providing this solution. Please let me know if a reboot is important if it works already without. Thank you. – Homestead

@Homestead glade to hear that it worked for you.. in some cases SSL related issue resolved but still not receive the POST / GET data on website then it may required to reboot so it will update the Cert Renew info in system and it will resolved the data receive issue. – Zymometer

Answer 2

I've got the same issue today, ok in webbrowser, SSL error in postman and some programming language call. My error was due to the root let's encrypt certificate expiration see announce here

using ssllab.com we found that it exists two chains of certifications for my certificate, one going up to ISRG Root X1 which was ok another one going up to DST Root CA X3 Self-signed the expired certificate (on Sept the 30th à 14:00 gmt)

To solved this issue, I update certbot to the last version (1.19) through snapd. the one in the packet manager of my ubuntu 20.04 was not the last one. (ref certbot doc)

Then I renew the certificate using option : --preferred-chain 'ISRG Root X1' note: looking to OP update, this is probably the default in the new release of certbot

and restart the service. since then everything is ok.

too confirm this is your issue, certification chain can be viewed through online tools like ssllabs.com

exemple of failing cert :

Certification Paths
Path #1: Trusted
 
1   Sent by server  asp.xyz.com
Fingerprint SHA256: 30c7865bd2fb4541e819bcfba43456b9fee3310b3faa8be8c86bd26a5cd6b15f
Pin SHA256: Iw4x0j6IktVzCyk1DsHyV5h8BuqXIq98VOhwLR0UWww=
RSA 2048 bits (e 65537) / SHA256withRSA
2   Sent by server  R3
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
RSA 2048 bits (e 65537) / SHA256withRSA
3   In trust store  ISRG Root X1   Self-signed
Fingerprint SHA256: 96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
Path #2: Not trusted (invalid certificate [Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739])
 
1   Sent by server  asp.xyz.com
Fingerprint SHA256: 30c7865bd2fb4541e819bcfba43456b9fee3310b3faa8be8c86bd26a5cd6b15f
Pin SHA256: Iw4x0j6IktVzCyk1DsHyV5h8BuqXIq98VOhwLR0UWww=
RSA 2048 bits (e 65537) / SHA256withRSA
2   Sent by server  R3
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
RSA 2048 bits (e 65537) / SHA256withRSA
3   Sent by server  ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
4   In trust store  DST Root CA X3   Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
EXPIRED
Weak or insecure signature, but no impact on root certificate

Fireworks

Many thanks for your reply. I can't run --preferred-chain 'ISRG Root X1' due to the age of my certbot, do you know how to do it manually? Struggling to find docs. Thanks. – Unchaste

even on ubunutu 20.04, provided certbot package is too old (0.40) for this option. you need to install the latest version trough snapd. It is installed on most linux. just check with snap --help. then update it sudo snap install core; sudo snap refresh core, uninstall os certbot version : sudo apt-get remove certbot (don't worry it can be installed later if their is a failure in the snapd version) and update the snapd version : sudo snap install --classic certbot. – Fireworks

I've updated my question with what worked for me, hopefully it will help someone. Thanks to all who answered. – Unchaste

The change is "just" in the certbot update as with the new certificate generation, there is only one certification chain while previously two coexistes but the second is now expired, but still used by some tools. I'll update my answer with that – Fireworks

This solved the issue I had when making call from Debian to an Ubuntu box hosting my API. PHP 5.6.4 client and Apache running on the host. Updating CA certs on both machines did not help, nor did upgrading the entire OS for both machines. Specifying the preferred chain immediately solved the issue. Issue was caused by the recent DST Root CA X3 expiration. – Frederiksberg

Answer 3

Same issue I was faced with CentOS 7.

My solution is:

1. sudo yum update ca-certificates
2. grep DST_Root_CA_x3 /etc/ssl/certs/ca-bundle.crt
3. remove DST_Root_CA_x3 cert if exists
4. restart your service

Byrann

I have had the same issue with CentOS 7. I use Virtualmin so I just updated certbot and ca-certificates packages, and right after that the issue was resolved. – Apriorism