Certbot automatic renewal vulnerabilities

问题:

I have certbot including automatic renewal in use in several installations with clients.

Now I have been reading here:

https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

here

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

and here

https://github.com/certbot/certbot/issues/5405

as well here:

https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811

everyone seems to be saying something slightly different

and no clear explanation is given.

I've been reading in the standard description of the certbot installation

Renewal docs point here:

https://certbot.eff.org/docs/using.html#renewal

but: the old vulnerable tls-sni-01 method is still listed

I try to summarize:

In the guides to mitigate existing issues on existing servers:

they recommend stop and starting the server on renewal. But... this is not good. What if some config breaks, and the server gets stop started when I am asleep? The server would be unavailable. Or something worse. I am not an devops expert but having the server more or less randomly start and stop, doesn't seem like a good solution. Am I wrong about this?

As alternative, I see only the webroot plugin that does not use tls-sni-01. https://certbot.eff.org/docs/using.html#webroot

that seems to be the only way to me, that seems reliable.

Am I missing something? are we basically told to use the webroot plugin?

as all others do use tls-sni-01, are not automated (you can do it manually but ehrm, I actually don't want to) or require you to not have a running server already (standalone).

That is for future servers. I guess existing domain renewals will continue to work with the old tls-sni-01, that is what they seem to be saying.

回答1:

so as I got no answers, I will have to assume that's what it is, e.g. use webroot plugin when possible.

What I actually found out is this:

the command certbot renew goes to the folder /etc/letsencrypt/renewal and checks the config files there. Those config files get created by the last time you triggered the certification process from command line. So if the last thing you did was use standalone, you will find standalone config there (you want to migrate away from that)

ok so now you run the first time the webroot plugin:

certbot certonly --webroot -w /var/www/html/www.mypage.com/public -d www.mypage.com -d mypage.com see here

this can, eventually, create a new entry in /etc/letsencrypt/renewal or overwrite the old existing one. Just be sure to delete the standalone one in case it did not overwrite but create a new file, you want only to have the webroot one there

now run crontab -e eventually have to be root user

add

53 14 * * * certbot renew --post-hook "service nginx reload"

this will run each day at 14:53 and reload the config and try to renew the certificates