acme/autocert: no supported challenge type found

这是使用 golang.org/x/crypto/acme/autocert 引发的错误，
背后的原因是 tls-sni-01由于可信的漏洞报告而被禁用。

相关链接
https://news.ycombinator.com/item?id=16112237
https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5a55777ed9a9c1024c00b241
https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996

官方解释：

Josh from Let's Encrypt here. I'm not able to give many more details yet, but here's what I can add now:
1) This isn't a relatively simple issue like a bug in our CA code would be. It's an interaction between the protocol and provider services.

2) Disabling TLS-SNI is a complete mitigation for us, meaning it's no longer possible to get an illegitimate certificate from Let's Encrypt by exploiting this issue.

3) We have not yet reached a conclusion as to whether or not the TLS-SNI challenge will need to remain disabled permanently.

4) At this point we have no reason to believe that the vulnerability has been exploited by anyone other than the researcher who figured it out and reported it to us.

Our focus now is on sharing information with relevant parties and looking for less drastic mitigations that might allow us to restore the TLS-SNI challenge option to people who rely on it.

We will, of course, share more information as soon as we can. That might be as soon as the next few hours, things are moving quickly.

知道你懒，(谷歌😂)帮你翻译好了：

乔希从我们这里加密。我还无法提供更多的细节，但现在我可以添加：
1）这不是一个相对简单的问题，就像我们的CA代码中的错误一样。这是协议和提供者服务之间的交互。

2）禁用TLS-SNI对我们来说是一个完全的缓解，这意味着通过利用这个问题不再可能从Let's Encrypt获得一个非法的证书。

3）我们还没有得出TLS-SNI挑战是否需要永久保持残疾的结论。

4）在这一点上，我们没有理由相信这个漏洞已经被研究人员以外的任何人利用过，他们已经知道了这个漏洞并且向我们报告了这个漏洞。

我们现在的重点是与有关各方共享信息，寻找不那么激烈的缓解措施，这可能使我们能够将TLS-SNI挑战选项恢复到依靠它的人身上。

当然，我们会尽快分享更多的信息。这可能是在接下来的几个小时内，事情正在迅速发展。