So how are we bringing TLS-ALPN to the masses?

With TLS-ALPN arriving, I am wondering what the envisioned way for “most people” to actually deploy it is?

For some background: ALPN is an extension in TLS that allows the application-layer protocol (http/1.1, h2, acme/tls-1) to be negotiated in the ClientHello/ServerHello messages of a TLS connection. A nice overview can be found at: .

For Let’s Encrypt, TLS-ALPN allows the validation process to be completed by including the acme/tls-1 ALPN ID in the ClientHello message, and responding with the same ALPN ID and ACME key authorization in the ServerHello response.

This means that the implementation of the validation process has to be done within the context of the TLS implementation of the web server, and the web server needs to know “what to do” when it encounters an ALPN ID such as TLS-ALPN’s.

What I’m finding is that a hypothetical deployment of TLS-ALPN by users today will involve one of:

  • Abandoning their current TLS termination (nginx, Apache, etc) in favor of a TLS proxy that is capable of implementing TLS-ALPN or passing-through the ClientHello. :x:. Nobody wants to abandon battle-tested TLS termination, it’s a big change.
  • Temporarily bringing down their web server’s 443 listener during validation, and allowing a “standalone” 443 server to complete the validation challenge. This is what Certbot does today. :x:. Downtime isn’t a strategy.
  • Temporarily (using netfilter/nftables) redirecting new connections to port 443 to a “standalone” server that is capable of serving both the application traffic and the TLS-ALPN traffic simultaneously. :x:. Seems overly complex and brittle.

So where do we go from here?

It seems inevitable that web servers will need to make some changes.

I don’t see TLS-ALPN being widely deployed (or at all) if it can’t practically fulfill the premise of the challenge: to enable validations over port 443 and truly replace TLS-SNI. Is any kind of progress being made, planned or proposed? I’d love to hear about it.


I imagine natural momentum will get it widely deployed, just not quickly. Give it two years for people to write patches for popular web servers, another two years for them to get merged, five years for new releases and stable distro uptake, and we can have half the world's web servers supporting it in less than a decade.


I don't like it, but that's not an unusual configuration. If only because people don't know there are better choices, and don't care about five or ten seconds of downtime every couple months.

1 Like

I am not completely sure what what is being validated here.
One single hostname? or a complete domain?
In case of the latter, that should mean this can be used to get a wildcard certificate right?

There are no plans to allow wildcard issuance with TLS-ALPN-01, only DNS-01.


While we’d like for TLS-ALPN to be widely adopted it is not meant to be a drop in replacement for TLS-SNI. Due to the changes we had to make to secure against the attacks which broke TLS-SNI it’s not likely to be something that individual users will be using, at least not for a while.

The existing DNS and HTTP challenges have proved to be relatively easy validation methods for individual users using off the shelf software. The main adopters of the original TLS-SNI challenge ended up being large hosting and other service providers who found it useful as they were able to handle all validation logic at the TLS load balancer/terminator level using custom software. This is the audience we expect to find the most use in the short term from TLS-ALPN.

That said as ALPN in general starts to see more widespread adoption it is more likely that TLS-ALPN support will be easily built on top of (or directly into) off the shelf software.


Maybe the temporary server could run on 444 and the original server could just somehow proxy the ALPN related requests from the expected standard 443 listener. So that the ALPN capabilities are not required in the running server and can still be satisfied. (best of both worlds)

In that case, the server does require a special ALPN capability: the ability to route connections based on the ALPN ID. So far, none of the major web servers can do this, except for an exotic configuration of nginx.

Looks like haproxy 1.8 can select the server certificate based on ALPN (documentation, git commit) and use the protocol name from ALPN in ACLs and other places (documentation); this may be enough to implement tls-alpn-01 when haproxy terminates TLS. However, the ability to route TCP connections based on the ALPN value in ClientHello without terminating TLS is missing (there is no req.ssl_alpn, only ssl_fc_alpn).


It could probably be prototyped for nginx in LUA through OpenResty very easily

I gave a shot prototyping a webserver-agnostic solution to see what it would take:

The gist of it is that it is a tiny singleton ALPN proxy that takes over port 443 using a prerouting redirection (iptables), load-balances between the ALPN authenticator and the actual webserver, then stops listening, removes the redirection, but stays alive until the connections have been fully drained.

The idea is that it should be simple to use with Certbot, and not require rebinding the webserver to another port, and no traffic is interrupted.

# Download it once to your Linux system
sudo curl -L -o /usr/sbin/acme-alpn-proxy ""

# Invoke your ACME client
# This is a speculative example, the standalone authenticator in Certbot does not yet support TLS-ALPN-01
certbot -d -i apache -a standalone \
--preferred-challenges tls-alpn-01 --tls-alpn-01-port 31443 \
--pre-hook "/usr/sbin/acme-alpn-proxy start &" --post-hook "/usr/sbin/acme-alpn-proxy stop &"

We expect that the Caddy web server will have fully integrated support for the tls-alpn-01 challenge, on by default and able to work without any configuration, just like http-01 currently does.

This pull request to lego adds support for it, which already works with pebble, and we’ll test it against staging on Tuesday in Caddy itself:


Update: I just integrated the TLS-ALPN challenge into Caddy locally, and will be pushing it to GitHub soon.

Caddy can solve the HTTP-01 challenge in a distributed fashion, if a fleet of Caddy instances are sharing the same certificate storage; I will try to get this working for the TLS-ALPN challenge next. In any case, I hope this will go out in the next release. It “just works” like the TLS-SNI challenge did, on port 443. No config needed.

(Thanks to the developers of the lego ACME library who implemented the new challenge type!)


I also doubt that which use cases need such tls-alpn validation method. That makes a ssl cert(LE cert) depend on a SSL connection. And if you want to pass the validation, you must bring down the current ssl server(server downtime), otherwise, the webserver must be changed for this feature.

Is there any statistics shows the current usage rate of the http-01, dns-01 or tls-sni-01 method in the passed year ?

Is there a must to have such a ssl based validation method, such as tls-alpn ?

The compelling use case (for my biases) for TLS validation is when port 80 is disabled by policy, such as when it is blocked by ISPs or other operational constraints. I recall a number of threads complaining about it in the short year I've been on this forum.

It's mostly about catching people at the edges where the friendliness of the solution suddenly takes a nosedive.

Thing is, if the UX of the DNS challenge wasn't so rough, I'd agree with Roland that TLS-ALPN could be left off end-user software. But it is really rough. The forthcoming ACME CAA extensions should enable trustworthy, third-party "assisted-dns-01" services to be built, so that's one way TLS-ALPN could be avoided.

I think the stats would be misleading.

  1. TLS-SNI was the default in Certbot for a long time, which would skew the stats in TLS-SNI's favor, even in the last 12m (since renewals are still going for many).
  2. Statistics don't count all the people who were either deterred from using Let's Encrypt, or resort to using it in a suboptimal way (manual validation/out-of-band issuance using e.g.

I don't think it's rough to just add a txt record.

I’d agree with Roland that TLS-ALPN could be left off end-user software.

Most of the users of LE are end-users. Big hosting companies never want to modify their ssl server or front end ssl proxy just for LE certs. It will be a big pain for security and performance.

TLS-SNI was the default in Certbot for a long time,

It's not a problem. Even though, I think there are little people use tls-sni method at all.

1 Like

I’ve also seen the same phenomenon as @_az. A number of people on the forum complain that port 80 is blocked by their ISPs (and some of them get quite angry about the nonexistence of a challenge that works on port 443, accusing Let’s Encrypt of lots of wrongdoing).

Really, the main thing that they liked about TLS-SNI-01 wasn’t anything about the technology, but just the fact that it worked over port 443.

So I think TLS-ALPN-01 support could be helpful to those users just for that reason. But it’s not all that clear how prevalent this situation is.


Huh? That's not true -- I can prove it if you want.

It's so that port 80 isn't required (HTTP challenge) and extra configuration with credentials isn't required by the user (DNS challenge). TLS-ALPN is my favorite challenge type, personally, for that reason.

:slight_smile: Clearly you haven't spent much time in DNS. It's tricky, with each provider having its own nuances. First of all, setting it manually is a nuisance and is to be avoided. And automating it comes with all the nuances I mentioned. Just take a look at the issues and PRs over at lego -- you'll get an idea of what I mean.

You'd be wrong, I think. Go's most popular ACME library, autocert, used ONLY the tls-sni challenge because of how convenient it was. (It broke when the challenge was disabled.)

Anyway, I'm just saying, I know lots of Caddy users prefer the tls challenge over DNS or HTTP when possible. It definitely has a place in the ecosystem. It definitely is needed.

If there was only the HTTP challenge or only the TLS-SNI challenge and one of them was disabled like TLS-SNI was, then all users would have to configure the DNS challenge pronto to keep their sites online. (Because there were two challenge types, and Caddy supported both of them, Caddy users continued to this day without any interruption.)

1 Like

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