Renew a cert with webroot plugin which was generated with standalone plugin


#1

So I had generated some certificates with standalone plugin, Which renewing the certificate can I just use webroot plugin?

Should there be any changes to Nginx configurations after the cert is renewed with webroot plugin?

~ Nik


Switching between plugins for renewal
#2

@Nik, This might be useful

You can use a config like

./letsencrypt-auto certonly -a webroot --renew-by-default --config /usr/local/etc/le-renew-webroot.ini

and then reload your nginx


#3

Thank you for the link @RijulB, but unfortunatel that does not answer my question.

I have already set up certificates using the --standalone flag which is working great but the problem is I have to stop nginx server every time I have to renew the certificates, because the --standalone option requires port 80 to be free.

The --webroot method does not require stopping the server and essentially taking down all the sites on the server.

So is it possible to renew certificates using --webroot which were installed using the --standalone flag?

~ Nik


#4

@Nik, my intuition is that if you say letsencrypt -a webroot -d example.org -d www.example.org with exactly the same list of domains as are in your existing cert, the client should be able to renew using your existing cert and the different authenticator. You would also, I expect, need to specify your webroot map on the command line, so it might be something like letsencrypt -a webroot -w /var/www/example -d example.org -w /var/www/example -d www.example.org. The key criterion is that the set of requested domain names (via -d) should be exactly equal to the domain names that are present in the original certificate, including any www names that might be present in the certificate.

If this doesn’t work, there is a way to do it by editing the renewal configuration file in /etc/letsencrypt/renewal; we tend to discourage this because we have not yet written any significant amount of documentation about the contents of these files and it’s possible to get the client into a non-working state by making a renewal configuration file internally inconsistent. With that warning, I would say that changing authenticator in that file and adding a webroot_map at the bottom can be used to change the renewal settings. The format of the webroot_map in the configuration file may be a bit counterintuitive and it might be helpful to make the changes based on another certificate lineage that was originally created using webroot, if you have access to one. As I said, we have tended to discourage this kind of editing for the time being because it is possible to get the client into an inconsistent state. If you end up needing to do this, we can try to help you make it work; it would be a good idea to back up your original renewal configuration file so that you can restore it if your edits confuse the client.

I hope that in the future we’ll have better tools and documentation around this topic.


#5

Thank you @schoen, Just Renewed my certs with webroot instead of standalone.

Running the same sites with webroot plugin for the same sites worked.

~ Nik


#6

Hi @Nik, I’m glad it worked for you! Hopefully eventually we’ll have a more convenient way to make this sort of change.


#7

Does a more convenient way exist now?


#8

It might be slightly more convenient to use --cert-name in more recent Certbot releases instead of specifying all of the -d values, if you know the lineage name for the certificate you want to modify (you should be able to find it with certbot certificates if you don’t). I haven’t heard of anyone using this to change the renewal method but in principle it ought to work as well as the method that I previously described.


#9

A post was split to a new topic: Renewal help for standalone with cron job


#10

@schoen, how can we do this using the certbot commands? I’ve installed a couple of sites using the --standalone method as well as 1 that I had to install using the --manual method because the site hadn’t launched yet and was hosted on a different server.

Trying to get these setup using --webroot so the webserver does not have to be stopped for renewals.

thanks!


#11

I think it will work if you just specify the new method with certonly like

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

as long as your list of domains in -d includes each and every domain in the existing cert. If the cert isn’t near expiry, you would also add --force-renewal to tell Certbot that you want an existing cert. The new authentication method should then be saved and used for all future renewals.


#12

Awesome, thanks, I got them all to work!!


#13

Hey guys!

I am facing the same problem - initially generated certificates with standalone plugin, but now I’m using a web-server (nginx). But I can’t afford to drop the site, in order to renew my certificate.

The only issue is, that I have my nginx running in a Docker container. I just want the auto-renewal, without having to drop the site.

Is it possible to somehow move to the webroot or nginx plugins?


#14

Yes, it’s usually straightforward. Are you running (or can you run) Certbot inside the same container as nginx?


#15

I’m running certbot in my host system. But I think I could run it in the same container as nginx.


#16

The nginx plugin expects to be able to modify the nginx configuration file and to restart nginx, so it will most likely need Certbot to be running inside the same container.