curl error checking releases: 7 - no recovery

[JakeQZ]

Describe the bug

user@host [~]$ ~/getssl/getssl -u -a -q
getssl: curl error checking releases: 7

To Reproduce
See above.

Expected behavior
If the getssl server is offline, the update should be skipped, but the obtenation of the SSL certificate proceed nonetheless.

Operating system (please complete the following information):

Linux 2.6.32-954.3.5.lve1.4.89.el6.x86_64 x86_64

Additional context
I've looked at the docs. Using -U or not using -u is not practical, because it's an automated process, and we do want periodical updates. But if the update server is offline, the command fails. And if you need to re-run a failed certificate grab because your site is offline, that's a bit of a PITA.

user@host [~]$ ~/getssl/getssl -a -q
getssl: curl error checking releases: 7

Also failing.

And

user@host [~]$ ~/getssl/getssl -U -a -q
getssl: ERROR curl "https://acme-v02.api.letsencrypt.org" failed with 7 and returned:

curl: (7) Failed to connect to 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable

I honestly think the banks and tech giants should be paying for security, not owners of small websites. If your account is compromised, who cares? Just create another one. If you get ripped off, get the bank to pay you back. It's their problem, and the least they can do for their 3% cut.

If Google lowers your SERP ranking, so be it. There are better ways of marketing than online.

Going back to http would improve transparency. What are you trying to hide?

[githubRover]

user@host [~]$ ~/getssl/getssl -U -a -q
getssl: ERROR curl "https://acme-v02.api.letsencrypt.org" failed with 7 and returned:

curl: (7) Failed to connect to 2606:4700:60:0:f53d:5624:85c7:3a2c: Network is unreachable

That is a comms error reaching the Let's Encrypt ACME server. It most likely is a problem on your end with your IPv6 routing or configuration. I say this because that IP is in Cloudflare which rarely has problems. Sure sometimes that happens but if the problem repeats you should try checking your IPv6 routing. You could start with something like:
curl -4 https://ifconfig.io
curl -6 https://ifconfig.io

If your IPv6 is broken that is likely a reason the getssl update is failing too. getssl does not have its own "server" - it relies on github which is a reliable source.

Both of these servers support IPv4 so if you can't get IPv6 working just remove it from your comms config

[JakeQZ]

curl -6 https://ifconfig.io/

curl: (7) Failed to connect to 2606:4700:e6::ac40:c210: Network is unreachable

Completed quickly, maybe due to cached result.

curl -4 https://ifconfig.io/

curl: (7) couldn't connect to host

It looks like the certificate we got was incomplete, for some reason. It works fine for the main domain, but not for the www. subdomain, Unfortunately the www. subdomain was the one we chose to use, and put in place 301 redirects.

Our ISP is TSOHost, but they have been taken over by the godawful GoDaddy. I've filed a support ticket, but it's the weekend. They offer "24/7" support. However I do not have time to waste in a two-hour long phone call while the "support representative" gets someone else, who in turn finally finds someone with a bit of technical knowledge, when meanwhile I'm put on hold.

I've looked on Let's Encrypt's website, and cannot find how to manually generate a new certificate.

The getssl command seems to work fine on my main GoDaddy hosting account, invoked via cron job. A certificate on one site was updated more recently than this failed one. And it previously worked on this account, just after GoDaddy took over.

I've wasted hours and hours on this. It's GoDaddy's fault, I am sure. The TCO with them should be better publicized. And it would be nice if they were not allowed to take over other ISPs and screw things up royally, but that may be too much to ask for.

Meanwhile, a website I'm responsible for maintaining continues to be effectively offline.

[githubRover]

If those two curl requests fail it is a problem with your comms outbound from your server. Yes, it would be an issue with your hosting company. I was expecting just the IPv6 to fail but it looks like both did.

Those curl requests are just routine HTTPS requests to a well-known site that has nothing to do with certs. They just return your public IP address.

Try reaching https://google.com with "curl -6" and "curl -4" and you'll get same result. -6 is for IPv6 and -4 for IPv4

The Let's Debug (https://letsdebug.net) test site is good for testing inbound to your server but not until you get outbound fixed.

[JakeQZ]

Try reaching https://google.com with "curl -6" and "curl -4" and you'll get same result.

Yep. Thanks for your assistance.

But the problem seems to be with curl, not the comms. wget works fine:

redacted@sxb1plzcpnl487428 [~]$ ~/getssl/getssl -u -a -q
getssl: curl error checking releases: 7
redacted@sxb1plzcpnl487428 [~]$ curl -6 https://ifconfig.io
curl: (7) Failed to connect to 2606:4700:e6::ac40:c210: Network is unreachable
redacted@sxb1plzcpnl487428 [~]$ curl -4 https://ifconfig.io
curl: (7) couldn't connect to host
redacted@sxb1plzcpnl487428 [~]$ curl -4 https://google.com
curl: (7) couldn't connect to host
redacted@sxb1plzcpnl487428 [~]$ curl -6 https://google.com
curl: (7) Failed to connect to 2a00:1450:4001:806::200e: Network is unreachable
redacted@sxb1plzcpnl487428 [~]$ wget https://wordpress.org/latest.zip
--2023-03-25 19:58:04--  https://wordpress.org/latest.zip
Resolving wordpress.org... 198.143.164.252
Connecting to wordpress.org|198.143.164.252|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 24369959 (23M) [application/zip]
Saving to: `latest.zip'

100%[======================================>] 24,369,959  7.35M/s   in 3.2s

2023-03-25 19:58:08 (7.35 MB/s) - `latest.zip' saved [24369959/24369959]

[githubRover]

If wget always works and curl always fails part of your network stack is messed up. That is very unusual. In any case, this problem isn't unique to getssl or Let's Encrypt for that matter.

Time to head to a network forum :)

[JakeQZ]

Time to head to a network forum :)

It's on a shared hosting server operated by GoDaddy (since they took over TSOHost). I've linked this issue into the ticket I created there. Hopefully will get some action after the weekend. Maybe they just need to switch it off and back on again.