4 ms·
In particular, autocert (https://godoc.org/golang.org/x/crypto/acme/autocert https://godoc.org/golang.org/x/crypto/acme/autocert) relies on tls-sni and does not
by regecks 9y ago
In particular, autocert (https://godoc.org/golang.org/x/crypto/acme/autocert https://godoc.org/golang.org/x/crypto/acme/autocert) relies on tls-sni and does not support the other DV methods.
Hopefully it is not fatal flaw in the design of the method, otherwise a lot of software will need to be re-built.
- jchw 9y agoYeah, I'm using autocert for a non-HTTP TLS server. It seems like the best option, but now I may have to move over to an HTTP or DNS challenge. Not ideal.
- enneff 9y agoI'm not an expert, but the autocert package appears to support both tls-sni-01 and tls-sni-02. The title of this HN post says "tls-sni-01" is disabled, but on the linked page it says "tls-sni challenge disabled". So I'm confused. Is tls-sni as a whole disabled? Or just tls-sni-01? If the former, then I don't think package autocert will continue to function. If the latter, then autocert users should be okay.
- pfg 9y agotls-sni-02 is not supported on the production ACME server. It is part of the latest ACME draft (ACME v2), which recently got deployed on Let's Encrypt's staging server, but the certificates signed in that environment aren't publicly trusted.
- enneff 9y agoThanks. So the upshot is that package x/crypto/acme/autocert can no longer obtain production certs. I have bumped this issue, volunteering to do the work to add http-01 support to package autocert: https://github.com/golang/go/issues/21890 https://github.com/golang/go/issues/21890
- rconti 9y agoAnd tls-sni-02 does not fix the problem.
- deleted 9y ago[deleted]
- niftich 9y agoFor LetsEncrypt, the acme-v01 API is the only production endpoint as of this time [1], which only supports the -01 version of tls-sni. [1] https://letsencrypt.status.io/ https://letsencrypt.status.io/
- peterwwillis 9y agoAll tls-sni has been disabled. The one production API, and two staging APIs, are affected.