Automatic renewal of certificate fails

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:
www.developmentscout.com, developmentscout.com
I ran this command:
certbot certonly --webroot --agree-tos --email struck.jens@gmail.com -d developmentscout.com -d www.developmentscout.com -d
It produced this output:
Domain: developmentscout.com
Type: connection
Detail: Fetching https://www.developmentscout.com/.well-known/acme-challenge/BNAtLGb1iwmcFWItdbfbz8CLoUP39QdDnH5-oYwFPF4: Timeout during connect (likely firewall problem)

There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see Rate Limits - Let's Encrypt

My web server is (include version):
Apache/2.4.38
The operating system my web server runs on is (include version):
Debian 10
My hosting provider, if applicable, is:
OVH
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): version = 0.31.0

2

Have changed the DNS-Zones files a couple of weeks ago and changed today the IPv6 address in the file (the last numbers were incorrect), because of failing to renew the certificates.

Unfortunately it was still not working, so I ran the "certbot rollback" command which gives me the rate-limit error.

Any ideas how to solves this would be highly appreciated.

Thanks

Jens

1 Like
3

Hi @Jens, welcome to the LE community forum :slight_smile:

The rate limit:

can only be overcome via the time restriction expiration.
That said, you could try getting two certs instead of one (one cert for each name); which might bypass the rate limit restriction.
That said, PLEASE use the staging system while testing and until all tests are passed.
--staging or --dry-run

4

The first thing I see is the attempt at https://www.developmentscout...

It looks like you are redirecting to https and www from your Apache server for port 80. That's fine when all is well but your cert is expired so the connection is failing. You should modify your port 80 apache server so it does not redirect requests for .well-known/acme-challenge/

I cannot speak to the rate limit message - outside my expertise. Perhaps you have just tried this failed attempt too many times in 3H? In any event, the new cert issuance will fail without resolving your redirect or using a previous good cert.

See crt.sh | developmentscout.com

5

Thanks guys for all your answers. Still trying to figure out how the staging system (with the correct command) works...

And yes, I'm redirecting all other domains and http with or without www to https port 443. And yes, if everything works, that's great. Now all my websites are down. So again, any help would be great :wink:

1 Like
6

That is actually NOT how LE does things.
As that would really put a damper on renewing any cert that has expired.
[you could even use a snakeoil cert, or a self-signed and expired cert, and LE will not care]

I do agree that redirecting an HTTP request for challenge requests is unnecessary and all such requests should be immediately handled via that initial HTTP request - but for different reason(s).

7

@rg305 thanks for the correction. That makes more sense

1 Like
8

The reasoning is that there is nothing private about the requested information.
So it matters not if it is obtained via HTTP or even via a bad HTTPS connection.

9

O.K. Very interesting discussion. Will definitely come back to this after everything is working...

In the meantime I have tried this:
certbot certonly --webroot -d www.developmentscout.com --dry-run

And got this output:
Failed authorization procedure. www.developmentscout.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.developmentscout.com/.well-known/acme-challenge/n-Za5MJyuSnCNoJeijfBiZjBXgmLFpplBkvmnn7LZ1E: Timeout during connect (likely firewall problem)

So same thing. Could it be, that this has something to do with changing my IPv6 on the DNS-Zone file because I have to wait for propagation? Any ideas how to solve this?

10

Yes, it might be related; As LE will prefer IPv6 over IPv4 (when present).

You must ensure that your site is fully functional via HTTP (via both IPv6 and IPv4) before being able to validate via HTTP authentication.
That said, you can test it as much as you like without limits on the staging environment (as you have done with --dry-run).

I see these:

curl -Iki4 www.developmentscout.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 08 Sep 2021 20:01:28 GMT
Server: Apache
Permissions-Policy: interest-cohort=()
Location: https://www.developmentscout.com/
Content-Type: text/html; charset=iso-8859-1

curl -Iki6 www.developmentscout.com
curl: (56) Recv failure: Connection reset by peer

[IPv4 works & IPv6 fails]

Using:

Name:      www.developmentscout.com
Addresses: 2001:41d0:700:3315::
           51.89.98.21
11

O.K. Does it make sense to delete all the IPv6 entries in the zone file to get a working certificate and after re-establiblishing the same stuff trying --dry-run?

12

BTW: when checking my site on this: IPv6 Test Tool it works...

13

Yes, if getting a cert is more important than fixing the IPv6 problem.
[high probabililty]

Well, that depends on your view of "How important are IPv6 clients?"
They will likely start to fail as soon as you add in a failing IPv6 address.
So... I would use a test site to add the IPv6 address to and when that one works, then add IPv6 to the real site.
i.e. IPv6test.developmentscout.com

14

Yes, getting a cert and running all the sites is very important. BUT due to some sources, reaching out a website with IPv6 is better from an SEO perspective, it should work of course. Thinking about the right approach. What would you recommend in this case?

15

I would leave the current site as IPv4 only and create a new test site for IPv6 only:

Name:      www.developmentscout.com
Addresses: 51.89.98.21

Name:      ipv6test.developmentscout.com
Addresses: 2001:41d0:700:3315::

Once all the IPv6 stuff has been corrected and working, then add the IPv6 address to the main site.

16

Thanks a lot for your recommendation. Tried this: certbot certonly --webroot -d www.developmentscout.org --dry-run for another domain after restarting web-server without IPv6 and changing Apache config but
netstat -plunt |grep ":80" gives only
tcp6 0 0 :::80.

So the result of the dr-run is still:

Failed authorization procedure. www.developmentscout.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.developmentscout.com/.well-known/acme-challenge/hgXXq07ERlJWoqV8gVdBuFGXBOg4O9FI2TQtfoI1Fig: Timeout during connect (likely firewall problem)

What do I have to change?

1 Like
17

And deleting the IPv6 stuff on the corresponding domain/DNS-Zone file of course.

18

Please show more of the LE log.
[it should show us exactly to which IP it tried and failed to connect to]

It seems the IP update has not yet synchronized (globally):
Let's Debug (letsdebug.net)

19

Here are the LE log:

Domain: www.developmentscout.org
Type:   connection
Detail: Fetching https://www.developmentscout.com/.well-known/acme-challenge/oM1m6YmnfI51xxobui8rP1qSQoXRZYJLFIqQJa-rmDE: Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
2021-09-08 22:51:43,719:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. www.developmentscout.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.developmentscout.com/.well-known/acme-challenge/oM1m6YmnfI51xxobui8rP1qSQoXRZYJLFIqQJa-rmDE: Timeout during connect (likely firewall problem)

2021-09-08 22:51:43,720:DEBUG:certbot.error_handler:Calling registered functions
2021-09-08 22:51:43,720:INFO:certbot.auth_handler:Cleaning up challenges
2021-09-08 22:51:43,720:DEBUG:certbot.plugins.webroot:Removing /var/www/vhosts/developmentscout.com/htdocs/.well-known/acme-challenge/oM1m6YmnfI51xxobui8rP1qSQoXRZYJLFIqQJa-rmDE
2021-09-08 22:51:43,721:DEBUG:certbot.plugins.webroot:All challenges cleaned up
2021-09-08 22:51:43,721:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1250, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 410, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 353, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 389, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. www.developmentscout.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.developmentscout.com/.well-known/acme-challenge/oM1m6YmnfI51xxobui8rP1qSQoXRZYJLFIqQJa-rmDE: Timeout during connect (likely firewall problem)

Have only deleted the IPv6 stuff for the *.org domain, NOT for *.com in the Zone files. Would this be a mistake?

20

Trying to eliminate all the IPv6 stuff for this server, but
netstat -nap | grep apache report that it is only listen to a tcp6 (port 80) address. Grrrr....

I thought it is hard to implement the IPv6 stuff, but obviously....