Using Certbot to generate new certificates without knowing current server/certificate state

Server
1

This question is regarding Certbot + Nginx and Apache. I’ll try to make this question concise, but it can be a bit hard, as the issue may not be entirely straightforward :slight_smile:

We are a VPS provider and have integrated Certbot in such a way that users can trigger certificate generation from our dashboard. We had no problems for a long time, but now certain issues have cropped up with Apache, which has made us realize that maybe our approach is not the best one.

We are doing things very simply: The user sets one or more domains which get set in the virtual host configuration of their webserver. We then run Certbot against the same domain list and force redirects.

The user can enter any domains they want. Now, this worked just fine and still works perfectly for Nginx, but recently Certbot makes a right mess of the Apache virtual host files if Certbot is run multiple times.

Meaning, if a user has generated certs once and then runs Certbot again, it usually fails with messages that it cannot set up redirects automatically, and frankly turns the virtualhost files into a crazy mess, which may even take the webserver down.

This made us think that maybe we had got off on the wrong foot all along. What we are thinking we might need to do actually is:

  1. Roll back (and maybe revoke?) any existing certificates installed on the server, so that certs are cleaned out and the vhost config is in a clean state

  2. Then run Certbot normally

“Problem” is that this workflow can get very complex if we need to save information regarding which certificates were generated and build custom logic to do rollbacks. This gets further compounded by the fact that our users have root access to their server, and can have messed around with config files in unexpected ways.

We have been searching forums and Github, but it is hard to get clear and concise information on the recommended workflow here!

We would prefer if Certbot was intelligent enought that we could just issue a rollback/revoke command before generating new certs - or that it was clever enough not to cause the breakage we are seeing (maybe I’m crossing into Github issue territory here, really). This would keep things simple, as in: We would not need to know anything about the current state of the server, but just issue a new cert generation on the basis of the new domain list.

So… In the end the question is simple, really, instead of just setting domains in the main vhost config and running the same command every time against the server:

certbot --webroot-path /var/www/html --authenticator webroot --installer apache|nginx --expand --non-interactive --agree-tos --email=user@mail.com --domains userdomain.com,www.userdomain.com,whatever.io --redirect

Are there other magic commands / workflow we should be using first?

2

Can you share an example of the Apache configuration that it’s failing to modify correctly?

3

Hey! Thanks for your reply

Do I take your request as a confirmation that what we are doing is actually not a bad way of doing things, and you should in fact be able to run Certbot on the command line as illustrated above, on your webserver, time and time again with varying domain names - if you so wish?

To me it is more essential to figure out if we are going about things in a retarded manner, and whether we should actually do some revoke / rollback actions first.

Because if your hunch is that this is either related to our specific setup (which is completely standard, absolutely no weirdness on our end) or Certbot weirdness, then I should rather take this issue to Github as it would then technically be a better fit as a bug report … Right?

4

The only thing I'd say against this way of doing things is that expanding the same certificate over and over increases the risk of running into the 20-certs-per-week-per-domain rate limit. There's also a limit of 100 domains per certificate. Other than that, yeah, it's fine. I have a script on a couple of servers I manage that does more or less the same thing. However, I don't use --installer there; I don't know how well it handles an expanded certificate, though I'd imagine that if it fails it would be considered a bug, yeah.

You definitely shouldn't need to revoke anything. As for rollback, it might be useful in some unusual situations but generally I don't think it should be necessary either.

That would be my hunch, yes. Although you are of course welcome to provide more details here too, in case someone can spot an obvious problem/solution :slight_smile:

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.