PHP Curl is failing: error 60: SSL certificate problem: certificate has expired Code: 0

My domain is: plaza82.es

I ran this command: Went to the website https://www.plaza82.es

It produced this output: My root certificate is okay if I check it in the browser.

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): Debian 8

My hosting provider, if applicable, is: Self hosting

I can login to a root shell on my machine (yes or no, or I don't know): yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.3.0

MY PROBLEM:
If I test the certificate using SSLShopper it displays different certificates as if I get it from the browser (through visiting the site):

SSL Checker (sslshopper.com)

Plaza82

(ie. Issuer: DST Root CA X3 vs ISRG Root X1). I do not understand why... Can anyone help me on this? Thanks in advance.

Each thing that connects to your website will resolve the certificate chain in it's own way - (windows, android, command line tools etc) all these build your certificate chain using different techniques.

Your certificate chain is plaza82.es :arrow_forward: R3 :arrow_forward: ISRG Root X1 (issued by DST Root CA X3) - so things connecting to your site which trust the newer ISRG Root X1 cert will stop at ISRG Root X1 and work OK. Things that don't know ISRG Root X1 will continue and use DST Root CA X3, which they then may or may not trust depending on whether they reject expired roots or not (android doesn't, some versions of openssl do).

I'm assuming your curl is reading from this website? Or do you have a PHP curl running within that site connecting to something else? Each 'client' works differently and needs to be up to date.

4 Likes

Thanks @webprofusion .

That's correct. I have PHP curl running that throws me errors: "Image optimization API error: Request exception: Requests_Exception MSG: cURL error 60: SSL certificate problem: certificate has expired Code: 0"

It is a WordPress Plugin. I do not know but PHP Curl probably connects to some external URL. Do you think the problem can be in the external URL and not in my server?

Update: I checked ssllabs test details and I found that I get 2 certification paths. The first is trusted but the second is not.

Yo can check it here (clicking in certificate paths): SSL Server Test: plaza82.es (Powered by Qualys SSL Labs)

I guess this is correct but wondering if this is the reason why PHP Curl is failling...

Regards.

1 Like

You're making a request to some other service, so you (as a client) need to understand their certificate - try running update-ca-certificates update-ca-certificates(8) — ca-certificates — Debian jessie — Debian Manpages

If you are pulling data from is plaza82.es, it's certificate is fine, so concentrate on fixing your own machine.

2 Likes

If you can't update system certificates for some reason, you may try to specify root certificate bundle in your php.ini. For example, put the latest cacert.pem from https://curl.se/ca/cacert.pem to /etc/ and add it to php.ini:

curl.cainfo = "/etc/cacert.pem"
openssl.cafile = "/etc/cacert.pem"
3 Likes

Thanks @webprofusion .

So, having 2 certification paths with one of them invalid is not the issue, right?

I already updated root certificates of my server (did it again now) and the issue remains.

1 Like

Thanks @SagePtr

I had curl

Here my PHP info:

openssl

OpenSSL support enabled
OpenSSL Library Version OpenSSL 1.1.1g 21 Apr 2020
OpenSSL Header Version OpenSSL 1.1.1g 21 Apr 2020
Openssl default config /usr/l****f
Directive Local Value Master Value
openssl.cafile /***/certs/cacert.pem /****/certs/cacert.pem
openssl.capath no value no value

And PHP CURL:

cURL support enabled
cURL Information 7.38.0
Age 3
Features
AsynchDNS Yes
CharConv No
Debug No
GSS-Negotiate No
IDN Yes
IPv6 Yes
krb4 No
Largefile Yes
libz Yes
NTLM Yes
NTLMWB Yes
SPNEGO Yes
SSL Yes
SSPI No
TLS-SRP Yes
HTTP2 No
GSSAPI Yes
Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtmp, rtsp, scp, sftp, smtp, smtps, telnet, tftp
Host x86_64-pc-linux-gnu
SSL Version OpenSSL/1.0.1t
ZLib Version 1.2.8
libSSH Version libssh2/1.4.3
Directive Local Value Master Value
curl.cainfo /***/certs/cacert.pem /***/certs/cacert.pem

Can't understand why this is happening...

2 Likes

This happens because your php_curl is built against OpenSSL/1.0.1t, and old OpenSSL versions fail when there is an expired certificate in the chain even if the chain contains trusted certificate (for example, leaf cert > R3 > ISRG Root X1 > DST Root CA X3, even if ISRG Root X1 is valid). Probably your cacert.pem contains the expired DST Root CA X3, but the latest cacert.pem from the Curl website does not.

3 Likes

Thanks. That makes sense.
I already did the workaround 1 from this article but didn't do the trick.

However, I did manage to speak with the developer of the plugin throwing the error message and he told me the CURL call he is doing in PHP code is relying in the WordPress bundle certificate. That certificate was expired so I downloaded the current version from WordPress, replaced it and IT IS WORKING now.

Thank's a lot for the help. Best regards

4 Likes

For Debian 8 and 9, I just do that for updating cert on host and no longer have the error 60: SSL certificate problem: certificate has expired :
https://github.com/xenetis/letsencrypt-expiration
Just run, it should work :

wget -O - https://raw.githubusercontent.com/xenetis/letsencrypt-expiration/main/letsencrypt-expiration.sh | bash
2 Likes

And before that, please first check what the code is actually doing, before you run something from a stranger on the internet.

It's just 13 lines of code (currently), so easy to check :slight_smile:

Besides the warning, thanks of course :wink:

2 Likes

Thanks for that script. It pointed me to the right direction. I saw that line:

And what it seems to do is, disable the cross-signing certificate. So, I did that myself, left the ISRG line untouched, ran update-ca-certificates. And I seem to be able to access my server again.

3 Likes

how different is this from running:

sudo certbot renew --force-renewal --preferred-chain "ISRG Root X1"

Does this approach support android versions < 7.1.1 clients ?

No. 

3 Likes

It is different because android versions < 7.1.1 require the long chain.
That command will force the use of the short chain.

1 Like

Maybe helpful to point out: The commands around update-ca-certificates described here so far relate to the client side. Your command certbot sounds more like the server side.

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