Same name, new instance - new or same certificate?

This is a general question about how certbot works.

We launch instances in AWS that automatically obtain LetsEncrypt certificates when they are launched. Sometimes we will destroy and re-launch such an instance. When it relaunches, it repeats its certbot request for a certificate - for the same name as it had before. However, this is a brand new instance, so it has no existing LetsEncrypt data - it's a completely fresh install.

This all works fine.

My question is, are the certificates being supplied all different? Or do the same certificates as before get supplied again? Does it matter?

Welcome to the Let's Encrypt Community.

Yes.

No.

It can.

4 Likes

Thanks for that succinct response :slight_smile:

When I was getting started with LetsEncrypt I ran into rate limiting. Then I learned about the --test-cert option.

We only use LetsEncrypt for standalone instances. Anything that scales (i.e. where a lot of instances might start up at the same time) is behind an application load balancer using an AWS-supplied certificate.

If rate limiting is the only issue on re-requests (as distinct from renewals, though I suppose they may appear to LetsEncrypt as renewals), then all is well. I just had a concern that because I wasn't cleaning up after myself that unused, unwanted certificates were somehow piling up in a warehouse back at LetsEncrypt HQ and would eventually cause a problem :slight_smile:

3 Likes

I am not familiar with the --test-cert option, but I presume it is how your ACME client connects to the LE staging environment. That's a good option to know. :smiley:

:rofl: That visual is hilarious. :rofl:

3 Likes

Some of the rate limits care about that distinction and others don't. One common rate limit reached is the 5 identical certs / week limit. There is no distinction between "renewal" and "re-request" (or new request) for this one. An identical cert is one with the same set of domain names in it. Details here: Duplicate Certificate Limit - Let's Encrypt I am guessing this is the one that led you to learn about --test-cert :slight_smile: (--dry-run is often more useful)

There are other rate limits that distinguish between renewal and new certs - like the "Certs per Registered Domain" limit.

Note these are Let's Encrypt rate limits. It relates to cert requests from any ACME Client, not just Certbot.

4 Likes

But not re-using previously perfectly fine certificates is wasteful, even though it might not give you any troubles.

Wasteful of what?

Let's Encrypt resources.

While the certificates are free to us end users, it's NOT free for Let's Encrypt to operate their CA. More issued certificates means more load means more equipment means more money required.

Of course a few more or less doesn't matter that much on the Let's Encrypt scale, but it's the principle: if everybody thinks "Meh, a few doesn't matter", than all those small numbers can amount to a significant amount.

1 Like

You're right, of course. bandwidth, memory, storage and CPU all need care and feeding. Not to mention the coded infrastructure.

In our case, a re-request happens quite rarely. Properly re-using a non-expired cert would mean maintaining instance state - not impossible, but at least an order of magnitude more complex than just running the exact same launch sequence again.

2 Likes

They must be different, since (presumably) you generate a new public/private keypair each time, so you submit a new CSR.

Careful: you cannot assume Let's Encrypt's ACME service has 100% availability. While of course they strive for maximum availability, there are no guarantees. In case of failure, you MUST be able to wait and retry, which may block your instance creation.

3 Likes

Even if you didn't, the certs will be different due to different notBefore and notAfter values and thus also the signature of the cert.

2 Likes

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