Renewal behind haproxy for TLS-SNI-01


the new support for nginx / apache is all nice & dandy, if one happens to use those.
I used tls-sni-01 through haproxy on my systems because the https connection go to a few different backends. (Like an ejabber server, nginx for one service, lighttpd for another, some other dedicated ones, several services running within a dockers container).

the haproxy dispatches normal https requests to the right ports (and server if needed) based on the SNI.
One of those is dispatched names is the acme validation to the certbot.
The names might be complete domains, but also several service specific DNS names.
in the case of multiple services names for a domain, then the certificate is requested for multiple names in that domain., (,,,…, in leu of a missing *

BTW, this TLS-SNI-01 renewal still works for ONE of the domains i run, the other 4 get the error that the current selected authenticator doesn’t work. (tried with dry-run).

I also fail to see how --apache, --nginx can help in this case.

Are the other 4 domains also renewals, or are they new issuances? And have you read TLS-SNI challenges disabled for most new issuance? Assuming the other 4 domains are indeed renewals, are they renewals using the same account that most recently issued for them? Otherwise, the renewal exemption will not work.

I just do certbot renew --dry-run (, they are not up for renewal just yet, only in a few days from now)
and receive 4 failure and one success

Ah, --dry-run uses the staging environment, which has a different set of accounts. If you haven’t previously issued certificates for those domains against staging, issuance will fail because the staging environment doesn’t see those issuances as renewals on your account.

So fingers crossed then… Thanks for answering this part.

What is the timeframe for continued renewals through tls-sni-01?
As http-01 won’t work (at least for all domainnames), how about support for automated dns-01 instead?
And how about support for wildcards? (would be nice as well).

This has been deployed.

Certbot has support for this, for many DNS providers. It's a little tricky at present because it requires installing additional plugins, which doesn't work well with certbot-auto.

Coming up in a couple months with ACMEv2.

With timeframe i mean, how long will tls-sni-01 continue to work, i get the impression it is now allowed to be a temporary stopgap.

Is there a reliable document how to setup automated dns-01?

Re wildcards, i had the impression tls-sni-01 was a prerequisite for wildcard support.

We haven't decided yet. The short-term response consumed all our attention last week. This coming week we'll discuss long-term plans.

I would recommend the Certbot documentation. If you set it up, and you find that documentation lacking, please do send improvements!

Nope, DNS challenges will be required for wildcard issuance.

Ok Thanks, some work todo…

See if you can direct HAProxy to direct all .well-known/acme-challenge requests to a single backend - that should probably get you a setup very close to what you have now.

The HAProxy dispatches on SNI, it doesn’t do HTTPS -> HTTP decoding
This way it can proxy one IP adres/Port to various services based on name, also for services that are further away behind a VPN connection, without need to handle certificates for those.

Yeah but the incoming http-01 challenge request would already be http so you wouldn’t need to decode it, just proxy it to a machine running an acme client…

Well how can the http-01 acme client listen to something DIFFERENT then port 80?
certbot renew takes no options… officially… :frowning:
inspecting the source learns that --http-01-port=8000 should work…
well almost…
using: certbot renew --dry-run --http-01-port=8000
the first domain fails only tls-sni-01 is attempted.
although both tls-sni-01 and http-01 are specified as access methods.

The other 4 do work, one with tls-sni-01… (the one that did “renew” before).
the others with http-01.

The first attempt is a certificate with quite some SAN’s attached. Some are scheduled for tls-sni-01 and http-01… the ones with http-01 fail.
Once the tls-sni-01 is removed all work.

adding http_01_port to the renewal config file does NOT work.

Yes, the --http-01-port option should tell certbot to listen on a different port (though of course Let’s Encrypt will still connect to port 80 - so you’ll want to have HAProxy listening on port 80, and it can then proxy to certbot on your chosen port).

What plugin(s) are you using?

  • If you’re using --webroot, I don’t think it supports the --http-01-port option; if you want to use a different port you would need to configure a webserver to listen there
  • If you’re using --standalone, it supports both http-01 and tls-sni-01 so you need to specify which you want it to use with the --preferred-challenges option
  • If you’re using --apache or --nginx, they don’t support http-01 yet so you’ll have to try out the new version currently in development, or wait for it to be released

BTW, I don’t mean to discourage you from switching to dns-01 if that seems to be a viable option for you - just describing an alternative in case it’s helpful :slight_smile:

But you should pass options like that to Certbot when creating certificates, not to “certbot renew”.

If you want to change options, you can run a similar command to what was used to create the certificate originally (with whatever changes you like).

1 Like

I am not interested to “changing” as well more or less (now) forced into change.
The certificates involved are several multiple SAN (Subject Alternate Names) certificates for one domain that for one domain ends up on several services with several of them (below tomcat, webrtc…) not supporting --webroot, some of them ending up on different systems…
lighttpd != nginx && lighttpd != apache. so that one won’t work as well.
The dns-01 approach looked too much like manual slavery each 3 months (although, hints were given here to other ways to solve that).

So the standalone through HAProxy approach seemed the only viable one. As port 80 at first was plainly blocked (my side), later reopened to blindly redirect all calls to https the http-01 wasn’t considered as tls-sni-01 worked until 2 weeks ago. (esp. as i don;t decrypt traffic in haproxy, just dispatch to the right server).

As i am interested in wildcard certificates @jsha told that dns-01 would be required anyway.
So it just means i have to change some things to my complete setup.

I only hope it doesn’t also require DNSSEC if the _acme_challenge zone is below a DNSSEC enabled zone. It could become a really interesting (ahem.) challenge 5 subzones, (at least 3 of them, but why keep 2 zones different from the rest). live updatable, DNSSEC recalc… the latter can take some time. I am afraid it would run into timeouts somewhere.

That would involve reregistering (AFAIK) and then also i need change the keypinning records i have in DNS.
Anyway check the renew/{domain}.conf files adding a http_01_port like tls_sni_01_port didn’t work out. So how would recreate the certificate work? The stand alone does need to listen to (in my case 8000) what ever method used. Passing the the option to certbot renew does work though.

@jsha, I haven't thought much about this concern before. When DNS providers allow updates via API, do they then normally store their DNSSEC signing keys online so that they can resign the updated zones immediately?

@Noci2015, one thing people have been pointing out is that you can use a CNAME to point the _acme-challenge record to a record in a completely different zone, which does not need to have the same administrator or the same hosting or the same authentication mechanisms. The CNAME record itself will never need to change (or only need to change infrequently if you redesign your authentication mechanisms), so if it's in a DNSSEC-signed zone, that signature doesn't have to be updated in order to perform ACME revalidations. The record that it points to will need to be changed, but that it can be located in a different zone of your choice.

1 Like

Ok thanks. I did see the separate zone mentioned in the dns-01 item i found.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.