Let's Encrypt certificate expiration notice for domain

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

We received ntofication that certs expire on 4 June. We believe this is misleading because our certs expire on 2022-08-03T10:10:24Z". See below. We have read similar support topics but want clarification that no certs will expire on 4 June. This is Kubernetes with cert-manager. The only thing that might have changed recently in our cluster is that some ingresses were no longer required so they were deleted.

I ran this command:
kubectl get certificate tools.begoib.com -o yaml

It produced this output:

  • lastTransitionTime: "2021-11-06T14:03:47Z"
    message: Certificate is up to date and has not expired
    reason: Ready
    status: "True"
    type: Ready
    notAfter: "2022-08-03T10:10:24Z"

My web server is (include version):

The operating system my web server runs on is (include version):
Ubuntu 20.04

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Unless LE's sending out erroneous expiration messages (which has happened, but is rare), you won't get such confirmation, because a cert will expire on 4 June. From the rest of the message, it sounds like you've replaced that cert with a different one--a cert with a different group of names on it. And in that case, an expiration notice is to be expected, because the cert for that exact set of domain names is expiring (and you're now using a cert for a different set of domain names). All of this is explained in the message itself.


Looking at the certificates issued for your domains:

Is there a (good) reason why you're issuing so many duplicate certificates so often? Note that Let's Encrypt certificates are valid for 90 days and usually there is no reason to renew a certificate within the first 60 days of its lifetime.

Anyway, if you look at the certs for the tools subdomain (crt.sh | tools.begoib.com), you can see at the top most 2 certs the relevant certs:

crt.sh | 6292038664 the cert expiring in June;

crt.sh | 6669766371 the cert expiring in August.

Take a look at the hostnames (Subject Alt Names extension). Please notice the difference between the two certs.

Once you've noticed the differences, please take a look at the Let's Encrypt documentation regarding Expiration Emails - Let's Encrypt (Also note that this page was also linked in the expiry email you've received.)

The expiry documentation should explain everything. Once you've appreciated the documentation page, I'm certain you'll agree with me that the expiry email you've received is not "misleading" as you've stated.



We are running multiple Kubernetes clusters and they all have a subdomain off

begoib.com and

The certs are created every time we build a cluster as part of the build workflow.

Once you've appreciated the documentation page, I'm certain you'll agree with me that the expiry email you've received is not "misleading" as you've stated.

Yes agreed. I think we are good.

Thanks for your very prompt response.

1 Like

Isn't it possible to have the certificates stored centrally in Kubernetes?


Hi, I did reply via email but realised that bounced.

It might be possible to store the certificates centrally in Kubernetes. We will look into this.

This could lead you into trouble with rate limits. While the certificates are free for you, each one does incur costs to the Let's Encrypt organization (in terms of tracking revocation status, auditing requirements, and so forth) and so it's best practice to be a good steward of their resources and not create more certificates than you need to. Please read through the Storing and Reusing Certificates and Keys section of the Integration Guide.