Score:1

Server

curl says a valid certificate is expired

tio oit

3/15/23, 11:41 AM

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)?

1998

0 + 0

certificate

curl

gitlab

Bob

3/15/23, 11:58 AM

The problem might be with an old Let's encrypt root certificate, rather than the actual server certificate. https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

tio oit

3/15/23, 1:03 PM

I used OpenSSL to get more info, and this is what I get : openssl s_client -showcerts -connect gitlab.mysite.com:443 </dev/null CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = gitlab.mysite.com verify return:1 And The let's encrypt and and ISRG certificates dates are not expired. Or am I missunderstandin something ?

Raul Benet

3/15/23, 1:21 PM

@tiooit what OS and version are you using ? What version of curl ? What version of SSL is curl using (if you are running Linux, you can find out by doing "sh$ readelf -d `which curl`" and look for entry containing libssl ] ?

Raul Benet

3/15/23, 1:28 PM

Sorry, formatting mangled the `readelf` command in the comment above - lets see if I get it right this time ```sh$ readelf -d `which curl` ```

tio oit

3/15/23, 3:58 PM

The server is running a `Debian 9.13`, with `curl 7.52.1`, but the `readelf` command does not show any libssl data

Raul Benet

3/15/23, 4:44 PM

It turns out that in Debian 9.3 (and possibly many others) `curl` first depends on `libcurl`, which in turn depends on `libssl`. Hence why you got no libssl data when issuing readelf. Checking on the Debian 9.3 repository, it shows that `curl` it is ultimately ussing OpenSSL 1.0.2d (this can be independent of your `openssl` package installation). And hence, you are very likely affected by the issue mentioned in my answer.

Raul Benet

3/15/23, 4:48 PM

In fact your question is probably a duplicate of https://serverfault.com/q/1079199/473319 and I would first try following answer: https://serverfault.com/a/1080278/473319

tio oit

3/15/23, 5:11 PM

You are absolutely right! Applying the mentioned answer's fix did resolve the issue, thank you :)

Score:3

Server

Raul Benet

3/15/23, 12:39 PM

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/

0 + 0

tio oit

3/15/23, 1:12 PM

Thank you for your suggestions. I checked OpenSSL version and it is 1.1.0l, so it should not be impacted by the bug you are reffering to. I also recently renewed the certificate but it still not working when calling the website from the server hosting it.

Paul

3/15/23, 2:17 PM

Ubuntu 16.04 is EOL. Please upgrade your server to a maintained version.

tio oit

3/15/23, 5:13 PM

For everyone looking for the solution, Raul Benet gave the solution in a comment in my question

Raul Benet

3/15/23, 5:41 PM

To make it more clear, I have enhanced the answer. @tiooit please accept it again, so it is marked as answered. Thx.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: curl says a valid certificate is expired

TH: curl บอกว่าใบรับรองที่ถูกต้องหมดอายุแล้ว

RO: curl spune că un certificat valid a expirat

RU: curl говорит, что срок действия действительного сертификата истек

VI: curl cho biết chứng chỉ hợp lệ đã hết hạn

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.