Incorrect expiration notices for some TLDs, ".news", ".report"

I own some newer TLDs like “.news” and “.report” and put SSL on them with Let’s Encrypt.

I noticed I was getting “Your certificate (or certificates) for the names listed below will expire in” emails that were incorrect. They say my certificates are going to expire imminently, and are worrisome, but when I check the certificate settings in Chrome, everything is fine.

I am running a cron job that checks for a renewal possibility every 22 minutes past the top of the hour, every hour:
/usr/bin/certbot renew -q --agree-tos my email here

I force renewed everything, so I can’t be 100% sure this “renew” command worked on its own for “.news” and “.report”. The certificates for “.news” and “.report” renewed properly, but nonetheless, the emails still occurred. I’m assuming the regular “renew” command does work for “.news” and “.report” because I’ve had these domains for more than a month, but the emailer is incorrect. The command does work fine for my “.com” TLDs.

Can someone please check into this? I think it’s a real issue. If this has already been reported or discussed somewhere, my apologies.

Hi @dgross,

Your renew command doesn’t seem to me to be structured correctly, because I don’t think --agree-tos takes a parameter (and if you’re using the same account, it normally doesn’t need to be repeated with renewals anyway).

However, did you check whether the list of domains in the current certificate is exactly the same as the list of domains in the expiring certificate? That is the criterion used for the renewal reminder e-mail. For example, if you added a new domain to the certificate, the old one is viewed as unrenewed, even though that is usually not harmful. A sentence further down in the renewal reminder e-mail is meant to point this out.

Edit: a good recent explanation of this is at

Sorry, I typed my cronjob command incorrectly. It always had the -m parameter before the email, i.e.:
/usr/bin/certbot renew -q --agree-tos -m my email here

However, I see what happened. You’re right. I have a duplicate. After running “/usr/bin/certbot certificates”

This has nothing to do with TLDs like described. Sorry about that. I think this issue is resolved.

1 Like

Great, I’m glad your certificate was renewed properly after all!

1 Like

Thank you very much.

At first, many months ago, I didn’t know how to use the command line prompt to group the .www and bare domain into one certificate. The two domain names I had an issue with, I did the same incorrect premise. I was trying to make a separate certificate for www and bare. Then I realized what was wrong, grouped the two correctly, and it left a duplicate lying around.

In current versions of Certbot, you can delete the old certificate with certbot delete, using its name as shown in certbot certificates (in order to stop certbot renew from trying to renew it, for example).

Perfect, thank you schoen. Great support! I highly appreciate this Let’s Encrypt community.

I accidentally deleted the wrong certificate, punched the wrong domain name in.

Is there an easy way to recover from this?

I can’t run “sudo certbot --apache” anymore because fullchain.pem is missing from the corresponding -le-ssl.conf file.

Fixed it! Whew! Sorry about that. I deleted the -lle-ssl.conf and it’s symlink in sites-enabled. Regenerated.

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