Hi,
I was struggling now a few hours, because I (was forced to) changed my INET provider... and it might be of course BECAUSE of my provider - but in short:
PLEASE implement for CHALLENGE/RENEW
the possibility to USE A DIFFERENT PORT than 80
a switch to increase the timeout for IPV6
background:
I am running a private a webserver behind vodafone (german provider)
now it only allows ipv6 as public ip address. Ipv6 is a pain. Have a look: media.ccc.de - Just Another IPv6 Talk
So of course I was struggling also with this
After several attemps, got it running BUT
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Timeout during connect (likely firewall problem)
with standalone commandline switch ( because my webserver is not on 80,443 ...) and
I decided to install another webserver only on 80 and only for 80 bot.
I found out - that FROM OUTSIDE it is sometimes slow and even a plain text file could go on a timeout, but only almost... firefox showed one time a timeout and then loaded the page.
It might be that my provider is filtering port 80 and making this esp. slow. Do not know - but I can confirm that in 1/20 tries even with dry run or without, I DO NOT GET THE TIMEOUT.
and now again stuck at:
Error creating new order :: too many failed authorizations recently:
If port 80 is blocked, but port 443 is accessible, you might be able to use the tls-alpn-01 challenge which uses port 443. However, Certbot does not implement this challenge, so you'd have to look for a different ACME client. Also, port 53 can be used using the dns-01 challenge.
Note that LE, as a public CA, is restricted to the ports allowed by the CA/Browser Forum Baseline Requirements, so LE can't simply make use of e.g. port 8080.
Let's Encrypt is required to use only port 80 for HTTP-01 validation per the CA/B forum baseline requirements.
If you need to use something else you can use 443 with the TLS-ALPN-01 challenge or DNS with DNS-01
Edit: Slow Internet and Osiris posted a better explanation, oops
I decided to install another webserver only on 80 and only for 80 bot.
I found out - that FROM OUTSIDE it is sometimes slow and even a plain text file could go on a timeout, but only almost... firefox showed one time a timeout and then loaded the page.
That's very unusual and I wouldn't expect things to work properly when this is the case. I don't think it's reasonable for Let's Encrypt to massively increase their timeout (which will tie up their resources) to accommodate a buggy webserver or internet connection when a viable workaround such as dns-01 exist
I personally handle challenges with Cloudflare's DNS API
Maybe to state this clear again:
I am not testing, I want to renew my cert behind ipv6 - on a different port fast.
Sadly the ipv6 port 80 is running in 19/20 cases on TIMEOUT - also WITH DRY RUN and without.
Its like hit or miss.
you could always say: buy better internet, do that, do this - in the end throw the bucks to a 5 years paid certificate.
I will look into dns and the TLS ALPN ... but it really would be nice to just change only the PORT or increase the timeout for ipv6 (as second switch)
That is not possible and let's encrypt is prohibited from doing that, except from the other options I listed
If let's encrypt allows you to use http-01 on a port other than 80 they will be distrusted and removed from the browser trust stores. Then nobody can use them
Those don't exist anymore, certificates are capped at 1 year. But if automatic renewal is unreliable on your connection paying for a certificate may be a better option
The staging environment is good for diagnosing issues as well, so you don't hit rate limits
You're running into issues. From that moment, you're no longer in "production" mode, but in "testing" mode. At least, IMO you should look at it with that mindset. Please use the --dry-run option when attempting to renew. This option makes use of the staging environment. Once everything seems to be working, you can remove the --dry-run option to renew using the production environment. Please see the Certbot documentation for the exact explanation of the --dry-run option.
Certbot is just the ACME client. Validation attempts are initiated from the Let's Encrypt validation servers. Certbot does not have control over these validation servers and the ACME protocol does not have any option to increase timeouts.
And I'm preeetty sure Let's Encrypt won't increase the configured timeout in Boulder for just a single user, sorry. But maybe I'm mistaken. In that case, a Let's Encrypt staff member might post here to contradict my statement made here.
@raspberryswirl If the delay is actually caused by your ISP shouldn't you complain to them? A prompt reliable connection is what you are paying for after all.
Are you sure the delay is not in your equipment and/or temp server? You have not provided the domain name or IP so we can't look at it. But, have you done traffic route analysis and such to isolate the failing component? Do you know how long a timeout would have to be to tolerate your situation?
