Certificate – Curl Says a Valid Certificate is Expired

certificatecurlgitlab

I have a gitlab community edition hosted on a server, and when using curl on this server to fetch this local gitlab website, I get an expired certificate error even if the dates are valid:

curl --insecure -vvI https://gitlab.mysite.com 2>&1 | awk 'BEGIN { cert=0 } /^\* Server certificate:/ { cert=1 } /^\*/ { if (cert) print }'
* Server certificate:
*  subject: CN=gitlab.mysite.com
*  start date: Nov 12 14:36:12 2021 GMT
*  expire date: Feb 10 14:36:11 2022 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: certificate has expired (10), continuing anyway.

But I don't get this expired certificate error when loading the site from a browser, or when using curl on another server. The error only appears when using curl locally, on the server hosting the gitlab ce instance.

This is the result when using curl on another server:

* Server certificate:
*  subject: CN=gitlab.mysite.com
*  start date: Nov 12 14:36:12 2021 GMT
*  expire date: Feb 10 14:36:11 2022 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

Is it possible that there is an issue because the curl is resolving to a local website (resolved ip = 127.0.1.1)?

Best Answer

I had those symptoms (works on browser, fails on Curl) on my Ubuntu 16.04 machine, curl 7.47.0.

In my case, the issue was indeed triggered by the Let's Encrypt expired certificate (as mentioned by Bob), but actually created by a bug on OpenSSL handling of multi-path certificate trees.

Ubuntu 16.04

This issue on OpenSSL has been patched on version 1.0.2g-1ubuntu4.20 (latest as of today) of the package for Ubuntu 16.04 (see changelog here).

If you are on Ubuntu 16.04 try updating OpenSSL to latest. If you are on other system check your version of OpenSSL. Versions prior to 1.1.x have the issue and require "patching" (as done for Ubuntu distro mentioned above). If you cannot move to use an OpenSSL version with a fix, then you can resort to disabling the certificate causing the issue. How to disable the certificate will vary depending on your OS/Distribution.

Debian 9.3

(updated answer - once OP identified the OS as Debian 9.3)
It seems that for Debian 9.3 this would be a duplicate question (I don't have enough privileges to mark it as such).
Client on Debian 9 erroneously reports expired certificate for letsencrypt-issued domain
And OP had success applying this answer (which is equivalent to my suggestion above for Ubuntu 16.04):
https://serverfault.com/a/1080278/473319

More information

Following page can provide more background information and pointers to understand better the issue. https://scotthelme.co.uk/lets-encrypt-old-root-expiration/

Related Solutions

Ubuntu 10.04/CURL: How to fix/update the CA Bundle

I've been having the same trouble and after poking around a bit found that you can download a package of CA-certs ready for curl on ubuntu directly from the curl dev site.

cd /etc/ssl/certs
sudo wget http://curl.haxx.se/ca/cacert.pem

Now curl uses the most up-to-date bundle and you're good to go.

Curl SSL Certificate – How to Debug ‘Unable to Get Local Issuer Certificate’ in Curl

Using openssl s_client -connect thawte.com:443 shows:

---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/O=Thawte, Inc./C=US/ST=California/L=Mountain View/businessCategory=Private Organization/serialNumber=3898261/OU=Infrastructure Operations/CN=www.thawte.com
   i:/C=US/O=thawte, Inc./CN=thawte Extended Validation SHA256 SSL CA
 1 s:/C=US/O=thawte, Inc./CN=thawte Extended Validation SHA256 SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3
---

That last "i" shows the issuing self-signed root CA. I'm guessing that that particular Thawte root CA, _i.e. the Primary Root CA - G3 cert, is not in your /etc/ssl/certs directory (as stated in the curl output; openssl s_client does not have a default CA path, and needs to given one explicitly, e.g. -CApath /etc/ssl/certs).

Adding that certificate explicitly to your /etc/ssl/certs directory (and re-running c_rehash) certainly wouldn't hurt. And if it works, e.g. as verified using openssl s_client -connect example.com:443 -CApath /etc/ssl/certs, then you know that that update-ca-certificates command may need some examination/debugging, as to why it hadn't picked up this root CA.

Now, it may be that the above root CA is already in your /etc/ssl/certs directory, and the above steps had no effect. In that case, there are two other issuing CA certs to check (at least in the cert chain offered by thawte.com:443): thawte Primary Root CA, and thawte SSL CA - G2. Repeating the above steps to install these certs into your /etc/ssl/certs directory (and re-running c_rehash) might work. Since these two are intermediate CAs, and not root CAs, the absence of one of them would explain your results, and might be expected as overlooked certs by update-ca-certificates.

Hope this helps!

Best Answer

Related Solutions

Ubuntu 10.04/CURL: How to fix/update the CA Bundle

Curl SSL Certificate – How to Debug ‘Unable to Get Local Issuer Certificate’ in Curl

Related Topic