There seems to be a lot of threads with conflicting info. Does certbot now support this Auth type and if so, how does the server need to respond to the Auth Request? Or does one nees to construct a request to the ACME server using openssl or aomething generic?
Certbot does NOT support the tls-alpn-01 challenge type, only the http-01 and dns-01 challenge types.
You can read more about the challenges here:
3 Likes
Ok - Thanks for the clarification. Can you point me to documentation about to use this type of Authentication withe ACME and what the required response looks like? Our server supports TLS-ALPN - HTTP/2 so I am wondering if we can get it working with this method.
If you're using Certbot: you can't.
The tls-alpn-01 challenge is mostly (exclusively?) used by webservers which have the challenge type integrated, such as Traefik or Caddy.
It doesn't matter if your e.g. Apache or nginx supports the HTTP/2 through the ALPN extension in TLS, that's not enough to get the tls-alpn-01 challenge type working.
3 Likes
It looks like dehydrated supports it which would be an alternative to using certbot. I do not have a web server per se with a plug in but a programable ADC - A Citrix NetScaler that terminates TLS and can have custom responses at most layers.
Do you actually require the tls-alpn-01 challenge? The http-01 challenge is way easier to implement. The only reason for using tls-alpn-01 I can think of is when incoming port 80 is being blocked by a pesky ISP, but which allows incoming port 443 for some reason. (Which is rather weird, why block port 80 and allow port 443..?)
2 Likes
That is the one. I am writing scripts for Citrix ADC customers, and I want to be able to be flexible with regards to options. Many do not allow port 80 externally - especially enterprises - which means they would be forced to use the dns method which may not work for test scenarios as they may not have control over the production domains. TLS-ALPN presents a nice solution to this to allow validation to occur.
As a sidenote, for security reasons, DNS-01 is best implemented by delegating the _acme-challenge DNS record onto a secondary DNS server. The acme-dns (GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.) project was designed to support this.
I believe acme.sh also supports TLS-ALPN-01
4 Likes
Port 80 is closed to help prevent MITM attacks and similar exploits that rely on unsecured ports being open. It is generally assumed that encrypted communications will occur over 443.
I can see taking that approach for uncontrolled outbound access.
But for controlled inbound access, that seems like using a sledgehammer to drive in a thumbtack.
The only two things inbound HTTP should ever need to do are:
- handle HTTP ACME challenge requests [directly or via proxy]
- forward all other requests to HTTPS.
These, of course, can all be done from a separate dedicated device, in a DMZ, with zero access to any real internal (or external) resources [other than to pass the /.well-known/acme-challenge/ requests] [which can be reproxied via a second system before reaching the internal system ("safety for the insanely paranoid" can be achieved)]
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.