We are having a heck of a time getting Certbot to behave properly when we want to issue new certificates after having changed webserver configuration.
This applies equally to Apache and NginX
What we first did was we’d just run Certbot again. Say we’d run Certbot once like so:
certbot --webroot-path /var/www/html --authenticator webroot --installer apache --expand --non-interactive --agree-tos --email@example.com --domains test.domain.com --redirect
and again like so
certbot --webroot-path /var/www/html --authenticator webroot --installer apache --expand --non-interactive --agree-tos --firstname.lastname@example.org --domains myrealdomain.com,test.domain.com --redirect
What we found was that it would then complain about existing configuration which Certbot itself had created for the webserver. This was only a problem on Apache I believe (should be easy to reproduce)
Then we started issuing a rollback command first. This solved the issue, somewhat, but now we have a bit of a catch 22: Certbot really likes, especially when it comes to Apache, that servernames are set up in the webserver config first.
But if we do that before the rollback, then that new config is lost and Certbot will fail. So now we have to do:
Set server names
Again, this gets a bit funky if the user has done any customization to their webserver config before we do this, as then that config will be lost.
Is there any “right way” of doing this?
I.e. any way of getting Certbot to understand that I have already updated server names in my webserver config and that I just want to update the list of domains?
Does this all maybe just stem from buggyness in how Certbot handles Apache, and we were doing the correct thing all along, and this is something I should post in the issue tracker instead?