Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In particular, 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.



I'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.


tls-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.


Thanks. 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


And tls-sni-02 does not fix the problem.


For 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/


All tls-sni has been disabled. The one production API, and two staging APIs, are affected.


Yeah, 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: