How realy works the --expand flag correctly?

[slart]

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
or
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?
or
All old domains + the new domain/s?
or
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.

[pfg]

@slart

Which command must be used?

letsencrypt renew --expand
or
letsencrypt certonly --expand

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.

@slart

Which domains must be insert?

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

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:

letsencrypt certonly --standalone -d example.com -d www.example.com -d mail.example.com --expand

@slart

Why are new csr & keys created for unsuccessful certonly?

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?

@slart

Why is the counter counted down for 5 in 7 days if not successful?

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.

@slart

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

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

[slart]

@pfg

You'll need to provide all domains that you want to appear on the certificate.

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?

/letsencrypt/accounts/acme-staging.api.letsencrypt.org/directory/bxxxxxxxxxxxxxxx9
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

/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/866d3cd132a050da576
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

/letsencrypt/archive/www.example.com
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

/letsencrypt/csr
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

/letsencrypt/keys
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

/letsencrypt/live/www.example.com
13.10.2016  11:02             2.147 cert.pem -> ../../archive/www.example.com/cert2.pem
13.10.2016  11:02             1.647 chain.pem -> ../../archive/www.example.com/chain2.pem
13.10.2016  11:02             3.794 fullchain.pem -> ../../archive/www.example.com/fullchain2.pem
13.10.2016  11:02             3.272 privkey.pem -> ../../archive/www.example.com/privkey2.pem

/letsencrypt/renewal
13.10.2016  11:02             1.807 www.example.com.conf

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

[pfg]

@slart

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.

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.

@slart

"Import" means, that the cert must import in the webhost. The webhoster don't import test-certs.

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.

@slart

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?

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.

@slart

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

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.

[serverco]

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

[slart]

puh strange

–expand
(missunderstod)
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
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, …)(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.

[slart]

Another question to:

full_cert1.pem

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