Timeout errors creating new certificate

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: https://biscotty.online

I ran this command:sudo certbot certonly --dry-run

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Runs an HTTP server locally which serves the necessary validation files under
the /.well-known/acme-challenge/ request path. Suitable if there is no HTTP
server already running. HTTP challenge only (wildcards not supported).
(standalone)
2: Saves the necessary validation files to a .well-known/acme-challenge/
directory within the nominated webroot path. A seperate HTTP server must be
running and serving files from the webroot path. HTTP challenge only (wildcards
not supported). (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Account registered.
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): biscotty.online, www.biscotty.online
Simulating a certificate request for biscotty.online and www.biscotty.online
Input the webroot for biscotty.online: (Enter 'c' to cancel): /var/lib/www/biscotty.online

Select the webroot for www.biscotty.online:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Enter a new webroot
2: /var/lib/www/biscotty.online
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: biscotty.online
  Type:   connection
  Detail: 76.127.10.154: Fetching http://biscotty.online/.well-known/acme-challenge/RS88CWc7BhBeBHkmeQNOOc7ocSTkbl_1kCTrJRN5Ipo: Timeout after connect (your server may be slow or overloaded)

  Domain: www.biscotty.online
  Type:   connection
  Detail: 76.127.10.154: Fetching http://www.biscotty.online/.well-known/acme-challenge/E8IuezyVN0OkVL1JPIvt1vy9k8dpieNjYpO4AXtS9kM: Timeout after connect (your server may be slow or overloaded)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): nginx 1.24

The operating system my web server runs on is (include version): NixOS 23.05.2664.9034b46dc4c7

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

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

2

Hi @biscotty666, and welcome to the LE community forum :slight_smile:

HTTP [TCP port 80] is required to use HTTP-01 authentication.
There appears to be something that seems like it is listening on that port.
But there is no web server being heard.

2 Likes
3

Hi,

Thanks for the quick reply. The site is live and accessible, which you can verify with curl -I http://biscotty.online. So I'm confused.

1 Like
4

If I try curl it opens the connection and hangs. If I try telnet 80 it doesn't respond to GET.

3 Likes
5

But I can't verify that - as I stated: something seems like it is listening on that port. But there is no web server being heard/seen.

5 Likes
7

Even VirusTotal is unable to complete its' scans in a timely manner:
VirusTotal - Analysing URL
click the button [and wait]:
image

3 Likes
8

As always with these things, try it externally because your local network may be working fine. So for instance try access the site over http from your phones mobile data rather than your own wifi.

I suspect you have a home or office router and you are supposed to be forwarding port 80 to an internal server IP?

3 Likes
9

Looks like: Comcast [Home Internet]

There might also be some sort of "bug-trap" or IPS that isn't doing what you expected.

3 Likes
10

If HTTP-01 authentication turns out to be no longer an option for you, you could try using an ACME client that supports TLS-ALPN-01 authentication.
OR
Switch to DNS-01 authentication.
[much more "complicated" - but a valid option (if you can get automated)]

4 Likes
11

At some point [well beyond 15 minutes connected], this happened:

curl -I http://biscotty.online/
curl: (52) Empty reply from server
3 Likes
12

I can't reach your domain using HTTP either and neither can the Let's Debug test site

But, I do get a response on HTTPS and a self-signed cert. At least that proves some connectivity using port 443 if this is in fact your system

openssl s_client -connect biscotty.online:443

subject=O = mkcert development certificate, OU = root@rpi (System administrator)
issuer=O = mkcert development CA, OU = root@rpi (System administrator), CN = mkcert root@rpi (System administrator)
notBefore=Aug 16 00:02:37 2023 GMT
notAfter=Nov 16 00:02:37 2025 GMT
serial=A0A07615275814F32EDB81C60036119B

SANs:
biscotty.online
4 Likes
13

Just tested from off-site and I can access it normally as well.

14

Thank you.

1 Like
15

This seems most likely. I've never had success with letsencrypt from this location.

16

The site works fine with the self-signed cert. And http works fine. I guess I'll just give up on letsencrypt.

Thanks

1 Like
17

Do you have a geographic based firewall?

We have tried connecting from various sites in the US and, probably Australia with no luck.

5 Likes
18

I'm not aware of having a geographic-based firewall. Perhaps comcast is doing some filtering.

19

Here is a site you can use to test how others see your site.

I would suggest trying DNS validation (proving domain control via DNS TXT record) or tls-alpn-01 (validation of TLS on port 443). For standard HTTP validation to work you need your system to be accessible over port 80 from multiple geographic regions.

3 Likes
20

Could the connectivity problems we have be related to your Sveltekit at all?

I am pretty sure we have all been trying things like curl or similar and not actual browsers. A quick read on Sveltekit looks like if not setup right could cause what we are seeing

I see these response headers when ignoring the faulty cert on HTTPS

curl -Ik https://biscotty.online
HTTP/2 200
server: nginx
date: Wed, 16 Aug 2023 02:50:02 GMT
content-type: text/html
content-length: 112607
access-control-allow-origin: *
etag: "g11a8o"
set-cookie: pb_auth=%7B%22token%22%3A%22%22%2C%22model%22%3Anull%7D; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; SameSite=Strict
x-sveltekit-page: true
4 Likes
21

Feel free to try it in an actual browser lol. It automatically upgrades to https (where currently you have to accept the self-signed cert to proceed). What you are seeing is expected for the headers. Could the automatic upgrade to https be interfering somehow?