我有certbot，其中包括与客户端进行的多个安装中使用的自动续订。
现在我一直在这里阅读：
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
这里
https://community.letsencrypt.org/t/solution-client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49983
和这里
https://github.com/certbot/certbot/issues/5405
同样在这里：
https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811
每个人似乎都在说些不同的话
没有给出明确的解释。
我一直在阅读certbot安装的标准说明
续订文档指向此处：
https://certbot.eff.org/docs/using.html#renewal
但是：旧的易受攻击的tls-sni-01方法仍然列出
我尝试总结一下：
在缓解现有服务器上现有问题的指南中：
他们建议停止并在续订时启动服务器。
但是...这不好。如果某些配置中断，并且我睡着时服务器停止启动该怎么办？该服务器将不可用。或更糟的事情。我不是devops专家，但是让服务器或多或少地随机启动和停止，似乎不是一个好的解决方案。我对此有错吗？
另外，我只看到不使用tls-sni-01的webroot插件。 https://certbot.eff.org/docs/using.html#webroot
那似乎是我的唯一方法，那似乎是可靠的。
我想念什么吗？我们基本上被告知要使用webroot插件吗？
由于所有其他人都使用tls-sni-01，因此不是自动化的（您可以手动执行，但我实际上不想要ehrm），或者要求您已经没有正在运行的服务器（独立）。
那是为将来的服务器。我想现有的域名续订将继续与旧的tls-sni-01一起使用，这就是他们所说的。
最佳答案
所以当我没有答案时，我将不得不假设是这样，例如尽可能使用webroot插件。
我真正发现的是：
命令certbot renew转到文件夹/etc/letsencrypt/renewal并检查那里的配置文件。这些配置文件是在您上次从命令行触发认证过程时创建的。因此，如果您做的最后一件事是使用独立配置，那么您将在其中找到独立配置（您想从中进行迁移）
好的，现在您第一次运行webroot插件：certbot certonly --webroot -w /var/www/html/www.mypage.com/public -d www.mypage.com -d mypage.com see here
最终可以在/etc/letsencrypt/renewal中创建一个新条目，或覆盖现有的旧条目。只要确保删除独立文件，以防它没有覆盖而是创建一个新文件，您只想在其中拥有一个webroot文件
现在运行crontab -e最终必须是root用户
加53 14 * * * certbot renew --post-hook "service nginx reload"
它将在每天14:53运行，并重新加载配置并尝试续订证书
关于ssl - Certbot自动续订漏洞，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48996982/