Expiration notice email... but it's not close to expiration!

Basic question...

I got an email saying I need to renew my certificate, and that it expires in 10 days.

So, I logged into the server that holds the certificate and ran "certbot renew" and IT SAID that my certificate is "not due for renewal yet".

Which one is true? How do I get to the bottom of what's going on here? Why would I get an email like that? Is there a way to find out if I created a cert and never used it?

1 Like

By reading the entire e-mail closely.

3 Likes

Welcome to the Let's Encrypt Community :slightly_smiling_face:

6 Likes

I'm sorry you see it that way, but while @griffin s might contain more words and more lengthy explanation, the expiry e-mail in fact does contain the info you needed to know.

Also, it might be helpful if you pointed out what information the expiry e-mail might be lacking in your view. Perhaps the Let's Encrypt team would welcome the input so they can make the e-mail better.

3 Likes

While the email may provide what I need to know, it is not written in a way that is useable for me and, I suspect, a LOT of other people.

To show what I mean, I've annotated what I thought upon reading the email in a screenshot of the email.

Ultimately, the biggest problem is that the FIRST link they provide is a link to their "Integration Guide". I had fully expected to see something related to what I need to do to fix my problem (like, "how to renew"). But it was just a long doc intended for "hosting providers"-- why !?

The sentence immediately before the link to the Integration Guide is...

"For Let's Encrypt's current 90-day certificates, that means renewing 30days before expiration."

That would lead ANYONE to believe that the following link will address "how to renew", but it does anything but that.

By the time I got through realizing that the "Integration Guide" has nothing to do with me, my frustration was high and I went to the forum link and posted my question. I assumed that the last link would be more of the same and I didn't go there until later.

So, that's my feedback. I think if the email skipped the "Integration Guide" link and just provided basic info for people who do not deal with certs on a daily basis it would be much better.

7 Likes

And that's excellent feedback, thank you! I must say, I agree. I think the integration guide is just mentioned as reference for the "renew after 60 days" advice. Maybe it would be better to put the link as reference in a footnote or something and don't emphasise about the whole large provider integration stuff.

I believe some time ago the e-mails were send per certificate, but that would mean sometimes users get multiple e-mails at once. So LE decided to integrate this into a single e-mail. I also believe users have already suggested to include more details about the to-be expired certificate by using e.g. serial numbers. But this hasn't been implemented (yet?) or was decided against, I don't know exactly.

I also think it would be better to change the order of the provided information. The link with the explanation about why one could get an e-mail despite having renewed (with different hostnames) should, IMO, be put above the link to the community.

@lestaff Any thoughts about the above feedback from @cadet ?

6 Likes

Thanks for the feedback, this is really useful! I'd definitely like to improve our emails. One of the big things on my mind is sending email about domain names that have expired rather than individual certificates; that can reduce a lot of false alarms. Your idea about removing the integration guide link (which is indeed not relevant to most people who receive these mails) is a good one.

Ever since we first implemented expiration emails (before launch), we've tried to group together multiple certificates that are expiring on a single account. That's both for the user's convenience and for appropriate use of email resources - if someone has 100k certificates on their account, and they are all expiring, we don't want to send 100k emails! :slight_smile:

10 Likes

@cadet, thank you for sending this feedback!

I agree that the e-mail would be more useful if it didn't lead to confusion about any of the points you mentioned.

To answer your questions (which hopefully will be clearer in a future revision of this e-mail):

There could be more than one for one site?

Yes, that is possible. One example would be if you have a content delivery network (CDN) that serves your site to the public, as well as your own "origin" server containing the authoritative content for your site. In that setup, both of them might have certificates covering your domain name, but the certificates would be issued to, and used by, different servers run by different people. The CDN version might also have additional names on it, for other people's sites or for other sites of yours that are also hosted by the same CDN. So the names on the two certificates might overlap without being identical.

Another example would be if versions or variants of the same site are provided inside and outside of a corporate network (one version for employees and one version for the general public). Even if the content on the two is the same, it is possible that they would be accessed in technically different ways which might lead to, as in the CDN case, having two different certificates that are present for the same name on two different servers or server configurations.

Why? does it take a long time to renew?

In this case, the idea is to leave a considerable safety margin in case the renewal fails for some reason, like a server outage or misconfiguration. This is especially important when people are renewing their certificates manually, or when people are unfamiliar with debugging a renewal failure, because it's always sad when people show up on this forum saying "my certificate expired yesterday, my site is down!" or "my certificate will expire tomorrow, and I don't know how to renew it!".

The safety margin of one month means that people will typically have one month to figure out these problems before they actually lead to an expiration and unavailability of the site. That is much less stressful for everyone involved than it would be to leave it to just a couple of days beforehand, especially if the debugging process is going to be complicated or involve a user having to research something or coordinate with other people.

When the renew process is fully automated (as Let's Encrypt strongly recommends), renewal usually completes in less than a minute, assuming everything is configured properly. But threads on this forum about getting to the bottom of renewal problems often take 2-4 days of discussion, especially if the person asking the question is in a different time zone from people trying to help.

I am surprised that Let's Encrypt can't tell that I have a valid up-to-date cert for the website that is far from expiration. Why else would such an email be sent?

The likeliest case is something like the public service vs. private service. Many Let's Encrypt certificates are only ever used on internal networks that aren't directly accessible to the general public. So Let's Encrypt can't tell if those certificates are in use or not, but can tell whether it remembers having issued an updated version or not.

This has caused confusion on a regular basis for many years, though, because Let's Encrypt is trying to be very cautious in case users have setups where they intentionally have multiple overlapping certificates at a time. As I discussed above, this is totally possible, but it's not the most common case, which in turn means that most renewal warning e-mails in this situation are false alarms. It doesn't seem that there's any way that Let's Encrypt could determine that automatically, since in the non-publicized-origin-server situation or the internal-corporate-service situation, the place that the certificate is actively getting used can't be located or tested by an outside partly.

The sentence about "If you've replaced this certificate with a newer one that covers more or fewer names than the list above" is supposed to reassure people in this case, but it's fairly common that people either don't read it or don't realize that it applies to their situations.

11 Likes

Thank you so much, @schoen, @jsha, @Osiris and @Griffin for the insightful responses !!

6 Likes

I love this whole thread! We are definitely going to take a good look at the emails and see what we can change/update for readability and utility. Thanks for all of your thoughts!

5 Likes

(post deleted by author)

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