Renew start delay on http-01

Is it possible to start the responder for the http-01 challenge and delay starting the cert renewal?
The background is that the node is behind a load balancer and the health checker must first recognize the certbot responser.

certbot version. Debian 9/10/11

If you mean the --standalone responder, then I don't think so, no.

I've encountered this issue in the past though. I worked around it by disabling the health check on the load balancer for the /.well-known/acme-challenge/ backend.

4 Likes

Yes, I use the --standalone responder.

It's probably not something that would be added to Certbot officially, but you might be able to hack a pause in one of the three functions performing the challenge in the standalone plugin: certbot/standalone.py at cb632c376f17dfd75306020a17248f3c33c1ab2f · certbot/certbot · GitHub

I've never used a "pause" in Python, so I wouldn't know how to, but Google probably knows.

4 Likes

Thanks for the tip, but we're using the original Debian packages and wouldn't like to change them.
Why is there actually no delay option for the standalone responser analogous to the dns, for example '-dns-cloudflare-propagation-seconds'? That would be very helpful in my case.

1 Like

Nobody wanted it enough to submit a PR against certbot, sounds like you do, @Osiris has pretty much given you everything you need for that. You would need a time.sleep(5) for instance but really the proper way to do this probably includes:

  • not using the standalone mode and serving the challenge responses yourself
  • using a pre-request hook to pause your healthcheck

I presume you are stopping your http service, running certbot as standalone, then starting it again which means you are incurring an outage for each renewal, so in a way your healthcheck is correct

How is this working anyway? Your load balancer is potentially going to serve the http challenge via the wrong server, unless only one server is configured for cert renewals and all /well-known/acme-challenge/ request go to that.

I recommend DNS validation for multi-server/load balanced scenarios as it skips this whole problem. If you then also use centralised renewal then you also avoid duplicate certificate rate limits if you have many server instances.

5 Likes

thx.

our use cases:

3 nodes with keepalived, one has the virtual IP and distributed.
A certificate is required on each node, which contains the host name plus the san names of the vHosts running on all nodes.
The certbot has been switched to port 81, and a distribution incl. health checker for post 81 has been set up on the LB.
Since we are not allowed to describe the DNS, and the DNS for the san names only points to the virtual IP, it would be nice if a delay during certbot and standalone challenge would be possible.

1 Like

Is that health check needed? The standalone auth is often very fast and at other times is not even running. My experience with such health-checks is to detect failed or non-responding instances. The important thing to know is whether certbot gets the cert properly. There are various other options for that.

3 Likes

Yes, of course the haelthcheck is necessary, because the LB should only forward it to the node that is currently carrying out the cert renewal.

Is it not possible for your webserver on port 80 to serve the http challenge responses? Certbot can write to a web root path, your webserver just need to know to serve the static text files from /.well-known/acme-challenge, which is a very common configuration.

2 Likes

I know the apache plugin, but how does the LB want to know which node is currently performing a renew?
Only the currently active cerbot client may be served by the LB?

I have a solution to the problem.
I use the track_file option in keepalived and write this file using the pre/post scripts.