How realy works the --expand flag correctly?

How realy works the --expand flag correctly?

--expand tells Certbot to update an existing certificate with a new certificate that contains all of the old domains and one or more additional new domains.

Which command must be used?

letsencrypt renew --expand
letsencrypt certonly --expand

Which domains must be insert?

Only the first (old) domain in the domain-row in cli.ini & /renewal/xxx.conf + the new domain?
All old domains + the new domain/s?
Every old domain + the new domain/s?

Why are new csr & keys created for unsuccessful certonly?
Why is the counter counted down for 5 in 7 days if not successful?

A cert with the flag --test-cert can't import. I don't see is it realy works. Same as --staging flag.

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 and, and want to add, your command might be:

letsencrypt certonly --standalone -d -d -d --expand

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).

1 Like

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.

More Details:
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?

13.10.2016  10:51                83 meta.json
13.10.2016  10:51             3.169 private_key.json
13.10.2016  10:51             1.103 regr.json

13.10.2016  10:35                83 meta.json
13.10.2016  10:35             3.169 private_key.json
13.10.2016  10:35             1.096 regr.json

13.10.2016  10:35             2.147 cert1.pem
13.10.2016  11:02             2.147 cert2.pem
13.10.2016  10:35             1.647 chain1.pem
13.10.2016  11:02             1.647 chain2.pem
13.10.2016  10:35             3.794 fullchain1.pem
13.10.2016  11:02             3.794 fullchain2.pem
13.10.2016  10:36             3.794 full_cert1.pem
13.10.2016  10:35             3.272 privkey1.pem
13.10.2016  11:02             3.272 privkey2.pem

13.10.2016  10:35             1.655 0000_csr-letsencrypt.pem
13.10.2016  10:46             1.675 0001_csr-letsencrypt.pem
13.10.2016  11:02             1.655 0002_csr-letsencrypt.pem

13.10.2016  10:35             3.272 0000_key-letsencrypt.pem
13.10.2016  10:46             3.268 0001_key-letsencrypt.pem
13.10.2016  11:02             3.272 0002_key-letsencrypt.pem

13.10.2016  11:02             2.147 cert.pem -> ../../archive/
13.10.2016  11:02             1.647 chain.pem -> ../../archive/
13.10.2016  11:02             3.794 fullchain.pem -> ../../archive/
13.10.2016  11:02             3.272 privkey.pem -> ../../archive/

13.10.2016  11:02             1.807

Additional question: Does the counter also count at --expand?

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 "", where "" 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 (,, ( etc ) ?

puh strange

I mean the domains/subdomains in the command line (example):
letsencrypt certonly --expand -d -d -d -d -d -d -d -d -d -d -d
realy ???
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, …)(,,, …)(,,, …) 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.

Another question to:


Why is there only a full_cert1.pem and no a full_cert2.pem?

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