Support challenge types other than http-01
Closed this issue · 3 comments
Looking through the code, only http-01 challenges are supported. It would be great if it could also handle tls-alpn-01, and perhaps even dns-01.
Tls-alpn-01 could probably be handled with almost the same code (just direct to https instead of http). Not sure about dns-01.
tls-alpn-01 is substantially more complicated than http-01 as you need to create a self-signed certificate rather than just responding with a value as with http-01. In addition my setup (and most others, I think) would require a web server restart to pick up the certificate used in validation.
The real advantage of this protocol seems to be that you don't need port 80 available. LE says the following.
This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers...
dns-01 would be much simpler to support and does provide the advantage of allowing wild-card certs to be issued. However, in the absence of somebody actually wanting to use this it's not the kind of thing I'd put in the code 'just in case.'
Of course tls-alpn-01 is more complicated. The use case I've seen for it, is for those whose ISP block port 80.
In terms of supporting it, I was thinking about support in acme-lw's internal library, because that's the part I'm considering using. I forgot about the command-line tool.
Adding support in the library should be relatively easy (ignoring testing), because the actual TLS-ALPN implementation is up to the external code called via the callback. It might be an idea if the callback could indicate that it's not supported, though.
I really don't think this is a use case I'm interested in supporting, especially given the complexity. Feel free to fork it.