我有certbot包括在客户的几个安装中使用自动更新。
现在我一直在这里读书：
这里
和这里
https://github.com/certbot/certbot/issues/5405
在这里：
每个人似乎都在说些不同的东西
并没有给出明确的解释。
我一直在阅读certbot安装的标准描述
续订文档指向此处：
https://certbot.eff.org/docs/using.html#renewal
但是：旧的脆弱的tls-sni-01方法仍然列出
我试着总结一下：
在减轻现有服务器上现有问题的指南中：
他们建议在续订时停止并启动服务器。但是......这不好。如果某个配置中断，并且当我睡着时服务器停止启动怎么办？服务器将不可用。或者更坏的事情。我不是一个专家专家，但服务器或多或少随机启动和停止，似乎不是一个好的解决方案。我错了吗？
作为替代方案，我只看到不使用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运行并重新加载配置并尝试续订证书