cURL error 60: SSL certificate problem: certificate has expired

Question

We running 2 application on amazon EC2 (backend.example.com & frontend.example.com). For that application, we used a paid SSL Certificate. That certificate expiration date at 2021 June. But today, we got an error -

cURL error 60: SSL certificate problem: certificate has expired (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

We check certificate expiration date, but there was no problem (2021 June). Then we follow this thread - curl: (60) SSL certificate problem: unable to get local issuer certificate (@Dahomz answer)

After that, when we curl example.com by - curl -v --url https://backend.example.com --cacert /etc/ssl/ssl.cert/cacert.pem, It working fine. Response like -

* Rebuilt URL to: https://backend.example.com/
*   Trying 127.0.0.1...
* Connected to backend.example.com (127.0.0.1) port 443 (#0)
* found 139 certificates in /etc/ssl/ssl.cert/cacert.pem
* found 600 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ******_RSA_***_***_GCM_*****
*    server certificate verification OK
*    server certificate status verification SKIPPED
*    common name: *.example.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: OU=Domain Control Validated,OU=PositiveSSL Wildcard,CN=*.example.xyz
*    start date: Mon, 04 May 2019 00:00:00 GMT
*    expire date: Wed, 07 June 2021 23:59:59 GMT
*    issuer: C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Domain Validation Secure Server CA
*    compression: NULL
* ALPN, server accepted to use http/1.1

But when we hit from frontend.example.com to backend.example.com by curl, it throws this error -

* Rebuilt URL to: https://backend.example.com/
*   Trying 127.0.0.1...
* Connected to backend.example.com (127.0.0.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/ssl.cert/cacert.pem
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / *****-RSA-*****-GCM-******
* ALPN, server accepted to use http/1.1
* Server certificate:
*    subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.example.com
*    start date: Mar  4 00:00:00 2019 GMT
*    expire date: Apr  7 23:59:59 2021 GMT
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*    SSL certificate verify result: certificate has expired (10), continuing anyway.

My curl code -

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://backend.example.com");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, fopen(public_path("c.log"), 'w'));
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
$output = curl_exec($ch);
$error = curl_error($ch);
$info = curl_getinfo($ch);
curl_close($ch);

Answer 1

I know this is an old thread, but I thought it's worth mentioning as I haven't seen in in the other answers.

Double check the system's datetime is correct, in my case the date was set in the future so certs where considered expired.

Answer 2

I fixed this on Ubuntu 22.04 in 2023 by running:

sed -i 's|^mozilla\/DST_Root_CA_X3\.crt|!mozilla/DST_Root_CA_X3.crt|' /etc/ca-certificates.conf
curl -sk https://letsencrypt.org/certs/isrgrootx1.pem -o /usr/local/share/ca-certificates/ISRG_Root_X1.crt
update-ca-certificates --fresh

source: https://github.com/cloudposse/bastion/issues/67

Answer 3

I managed to fix the problem by running updates on my server:

sudo yum update

This seems to have fixed any issues with the curl certificates.

Answer 4

change or edit the settings below:

server key = A server key is a private encryption/decryption key used by the server.

Intermediate Certificate (CA) = Certificate Authority (CA) is an entity that issues digital certificates which will verify the ownership of a public key by the named subject of the certificate.

Domain Certificate = A domain certificate is an electronic document that is given by the Certification Authority which checks the permission of the applicant to use a specific domain name.

Answer 5

For ubuntu 14.04

Open your terminal

sudo su
wget https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rfBO -O SHA-2_Root_USERTrust_RSA_Certification_Authority.crt --no-check-certificate
cp SHA-2_Root_USERTrust_RSA_Certification_Authority.crt /usr/share/ca-certificates/mozilla/

Then dpkg-reconfigure ca-certificates and uncheck mozilla/AddTrust_External_Root.crt and check mozilla/2_Root_USERTrust_RSA_Certification_Authority.crt
or run sudo update-ca-certificates for uncheck those.

Answer 6

To fix the problem, remove the expired root certificate from your domain certificate.

1. Go to https://whatsmychaincert.com
2. Test Your Server
3. If they confirm you you have an expired root certificate, download and use the .crt without this certificate.

Answer 7

You could enable insecure connections adding this option to your $HOME/.curlrc file:

$ echo "insecure" >> ~/.curlrc

Do not recommended to keep this permanently, but, for quick and temporal solutions this is a good option.

Reference: How to apply the changes for all HTTPS connection

Answer 8

Yesterday I ran into the problem @finesse was reporting above. Since on our system the ca-certificates get updated automatically, I was quite troubled since the certificate was valid

• using curl on the command line
• using a php script with php-cli

but it did not work from the web site.

Solution was simple:

just restart php-fpm :/

Best regards,

Willi

Answer 9

I had to fix this issue on a debian based server

this was due to the system use of openssl (curl depends on openssl)

here is how it went:

1. remove AddTrust_External_Root.crt from your system (usually found in /etc/ssl/certs)
   2. remove or comment the "mozilla/AddTrust_External_Root" line from /etc/ca-certificates.conf
   3. run sudo update-ca-certificates to update the certificates used by openssl

maybe it can help you ?

Answer 10

We had the same issue, after some troubleshooting we found that the root certificates of COMODO where expired.

Valid until Sat, 30 May 2020 10:48:38 UTC (expired 3 days, 5 hours ago) EXPIRED

We tested this via: https://www.ssllabs.com/ssltest/index.html. And we resolved it by downloading the certificates freshly from our reseller.

This is the result we received about the COMODO certificates

Answer 11

We have the same error. For solving your issue update your "SSLCertificateChainFile" with the newest version of your trusted SSL site. In our case is comodo.

You need to go to your trusted site and find under your certificates the "CA-CRT". Copy the content.

1. Go to your /etc/apache2/sites-available
2. Find the line wih "SSLCertificateChainFile".
3. Next edit the file and replace the content with your new CA-CRT values.
4. Then restart your web server, in our case is apache: service apache2 restart or systemctl restart apache2

If you can't restart apache the easy way is reboot your instance.

Answer 12

A permanent solution would be to reissue the SSL certificate from your provider and reinstall it on your server.

The reissued certificate would update the CA bundle.

Cheers!

Answer 13

It seems like your truststore is not updated with the latest trusted root. Understanding that it happened to you beginning yesterday 30th May. I am assuming that you have Sectigo as your CA.

Update your trustore and you should be able to connect.

https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

Answer 14

If you're having this issue with "curl" (or similar) on a Ubuntu 16 system, here's how we fixed it:

On the Ubuntu 16 system hosting the curl / app that fails:

• nano /etc/ca-certificates.conf
• Remove the line (or comment) specifying AddTrust_External_Root.crt
• apt update && apt install ca-certificates
• update-ca-certificates -f -v
• Try curl again with the URL that was failing before - hopefully it works now :)