I have a GoDaddy virtual private server that comes with cPanel / WHM installed. I turned off the proxy redirects so I could use letsencrypt-auto’s web root plugin, so I don’t have to shut down my server to renew the SSL certs.
Should I revoke my current SSL certs (I have a bunch, like whm.mydomain.com, cpanel.mydomain.com, webmail.mydomain.com, etc) and then generate test certs, to make sure it works correctly without me needing to shutdown my actual server? Or should I just try generating new test certs and if it works, just generate the new certs and not worry about the old ones? I don’t want to get in trouble for requesting too many new certs. I think this will be the third time I’ve gotten real certs without any renewing.
The rate limiting is currently for the total number of certs issued within a period of time, regardless of their relationship to any prior certs. There is nothing that you can do to prior certs that increases or decreases the number of certs that you can issue at the present time. The CA doesn’t even internally track whether a cert is a “renewal” (at least not for rate limiting purposes). Revocation in particular does not affect or reset the rate limit.
Creating test certs is a great idea if you’re not sure about your configuration; you can do that, for example, with the --staging option to the client (in 0.4.0 you can instead specify --dry-run to confirm that the staging certs should be obtained but not installed).
It’s possible to use multiple webroots, and that’s probably appropriate for your situation, but you have to interleave the -w and -d options so that the client knows which webroot applies to which domain. You don’t specify all of the -ds together and all of the -ws together, but rather alternate them. This should be further described in the documentation on our web site, I think.
Thank you for your reply. I understand what you mean about interleaving the -w's and -d options. So, for the current SSL certs, I shouldn't revoke them?
I'm a bit confused about the --staging (--dry-run) option. I'll download the latest version from the repository before I try this. Before, I just passed a --test-cert option to Let's Encrypt. Should I not be using that but instead be using the --dry-run or --staging option?
Hi Spork, revoking the current certs has no benefit unless you’re concerned that their private keys could be compromised.
--staging is an exact synonym for --test-cert; they have the same effect. --dry-run is new in 0.4.0 and it additionally does not try to install the cert or save it (so you can use it just to confirm that you would be able to get a cert using a particular configuration, without changing the current configuration at all).
Hello schoen. Sorry for all the questions here. I should move the /etc/letsencrypt directory first and then run the letsencrypt-auto --dry-run stuff, right? If everything goes fine, then when I run without the --dry-run option, I don’t want the old certs conflicting with the new ones, right?
My setup and Letsencrypt work great installing new certs. Just reading about good ways to renew and ran into the glitch below. I appreciate any assistance I can get on this issue. Thanks!
Checking for new version…
Upgrading letsencrypt-auto 0.4.0 to 0.4.2…
Replacing letsencrypt-auto…
cp /tmp/tmp.ibPQjux6v2/letsencrypt-auto ./letsencrypt-auto
Creating virtual environment…
Installing Python packages…
Installation succeeded.
Requesting root privileges to run letsencrypt…
/root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade --help --debug
–
./letsencrypt-auto: 1810: ./letsencrypt-auto: tag: not found
user@myserv:/opt/letsencrypt# letsencrypt renew --dry-run letsencrypt: command not found
It’s a problem with the way that letsencrypt-auto updated itself. In my understanding, your letsencrypt-auto should now be up-to-date and you shouldn’t see this problem when you run it in the future.