You’d use the command with certonly (or --apache, etc.), but not with renew. Basically, you use the same command you originally used to get the certificate, plus --expand.
You’ll need to provide all domains that you want to appear on the certificate. As an example, if you originally got a certificate for example.com and www.example.com, and want to add mail.example.com, your command might be:
If the command fails, no new files should be created (or modified) in /etc/letsencrypt/live. I’d recommend ignoring any other files in /etc/letsencrypt - consider those client-internal files. In case I misunderstood the question: can you provide more details, like the error you got, and which files were created?
The counter is increased whenever a certificate is actually issued. If the client is unable to save those files for some reason (again, I’d need to see the error to say more), that’s not something the server would know or care about, as the resources to sign a certificate were already consumed.
What do you mean with “import”? Using --test-cert will do the exact same thing as the production environment, the only difference is that certificates issued by that server are not trusted by browsers, and that the rate limits are higher than production (hence the recommendation to use it for testing).
Realy? That’s realy much by more than 5 domains. I have tested it. It’s works, when only the cert-domain (common name:) is listed. Only by certs with similiar domains gets a (error) message. This can happen if old certs are present.
“Import” means, that the cert must import in the webhost. The webhoster don’t import test-certs.
I have created a brandnew cert and import this in the webhost.
Than i have make a --staging.
Than a not-up-to-date renew-script have make a renew. (out of control/broken).
The new renew-cert is not required. It will not be imported. So it will never be in use. But the counter counts?
With “5 domains”, are you referring to the rate limits? Note that the rate limits are not “max. 5 domains”, but rather you can get a maximum of 5 identical certificates per week (were identical is defined as covering the exact same list of (sub)domains).
The second rate limit of 20 certificates per registered domain per week means that you can’t get more than 20 certificates for subdomains of “example.com”, where “example.com” is the registered domain (typically the domain you bougt from your registrar).
Again, this is a limit on the number of certificates - it’s perfectly fine to get one certificate for up to 100 (sub)domains, and that’ll only increase your rate limit counter by one. A more detailed description of the rate limits can be found here.
If there’s still some confusion, it might help if you could post the command you’re using and the error you’re getting - I’m not sure I have understood the question fully.
That makes sense. The purpose of --staging is to allow you to test the process of obtaining a certificate without increasing your rate limit counters in production and locking you out of getting new certificates for a week. They’re not intended to be deployed to a real web server.
Based on the files, it looks like you successfully obtained two certificates, so your rate limit counter would be at two. Without knowing what the error during renewal was, I can’t really say more about that. However, the rate limits are independent of whether you actually start using the certificate. The resource that’s being limited is the signing capacity that Let’s Encrypt has - you successfully obtained a certificate, hence the counter was increased. Otherwise, a malicious user could get an unlimited number of certificates by simply not starting to use them.
Yes, when you use --expand, it’s really no different from getting any other new certificate, so the counter is increased. Any change to a certificate (renewal, changing the domains, the public key, etc.) requires a new issuance.
Can I just check on what @slart is meaning by “the counter increased” ?
Are you meaning the rate counter ( that @pfg has been talking about in his answer )?
or are you meaning the file names with a number on the end … chain1.pem, chain2.pem etc ?
or even the folder names (example.com, example.com-0001, example.com-0002 ( etc ) ?
I mean the domains/subdomains in the command line (example): letsencrypt certonly --expand -d example.com -d www.example.com -d ww1.example.com -d ww2.example.com -d ww3.example.com -d ww4.example.com -d ww5.example.com -d ww6.example.com -d ww7.example.com -d ww8.example.com -d new.example.com
Or only the “common names:” domain + the new domain (without the “alternative names:”)?
(i remember me on a error message near: “too much similar certs with this domain/s”)
Question: When is creating new files and folders with numbers (chain1.pem, chain2.pem, …)(example.com, example.com-0001, example.com-0002, …)(example.com.conf, example.com-0001.conf, example.com-0002.conf, …) is the rate counter are count?
Or, count the counter by every “letsencrypt certonly”?
The BIG PROBLEM with the rate counter is (speaking for many users):
Users creating lost/false Certs for your homepages and must wait 7 days for creating a right cert.
And this at many times by add/del a new/old domain/subdomain in a current cert.
Yes, the only valid way for add/del domain/s within a current cert is: delete the current cert and generate a brandnew cert. That’s not realy fine.