Why is Let's Encrypt emailing me saying "Your certificates will expire in 10 days" about dnalounge.com? As far as I can tell it doesn't expire until August.
The email lists every domain in that cert except for mta-sts, which was added recently.
"certbot renew" says "Cert not yet due for renewal" for every domain. Version 0.31.0.
Looks like that was probably your old renewal date, your certificate renewed on the 13th of this month, possibly automatically. Was it sent before the 13th, or after?
It was sent today, May 22.
I've had Let's Encrypt email me telling me a certificate is going to expire on ${date} the certificate I'm using actually expires later than ${date}. It was because I had obtained a new certificate, with an extra Subject Alt Name and not done anything about invalidating the old one. You say
mta-stswas added recently. So when you addedmta-sts(on 13th May?) that meant getting a new certificate, right? So the expiry email is for the previous certificate. That's my theory anyway. I remember the expiry email giving no information about the certificate other than domain and expiry.Ok, that makes sense.
When I have needed to add a new domain or subdomain to my cert, I have done that by just re-running the long "certbot-auto certonly --debug --webroot -w ... -d ..." command with the new domain added, and it overwrites the files. Is there some more correct way to accomplish that?
If there's a more correct way I would be happy to see someone else enlighten us both. :)
AFAICT that’s the correct method to change the alt names. But to avoid both versions of the cert being renewed, you need to explicitly revoke the old version of the certificate.
Part of the problem is that it does not overwrite files when you get a new version of the cert; they live on in the archive directory forever, and they just update symlinks.
My current approach is to avoid alt names if at all possible, get single domain certs, and rely on SNI to serve the correct cert. There are relatively few browsers still in use that don’t support SNI.
Ewen
What you did seems fine. The reminder robot is intentionally very dumb, it will remind you about any set of names for which you had a certificate and it's expiring but nobody has a new certificate from Let's Encrypt for the exact same set of names. If you have an idea you're actually sure is better for everybody you could try proposing it, but don't get your hopes up - there's a reason they went with the very dumb option. The robot will stop bothering you once the certificate it's worried about actually expires.
You might look at incantations involving --cert-name to be explicit that you are definitely looking to replace a specific certificate, as otherwise it's just guessing and if it ever guesses wrong it may either create a separately named certificate file for the new cert, or contrariwise overwrite one you need with a new one you expected to go into a new file. If you're explicit about which certificate you mean then it's only your fault if you pick the wrong one.
Sometimes you will see people advising revoking old certs. As a general rule this is either pointless or actively counter-productive. Obviously if scumbags actually broke into your server and copied the private keys then revocation makes some sense (though it isn't terribly effective) but especially for short-lived certs it's nonsense to revoke them just because of routine replacement. Last I knew, it doesn't touch Let's Encrypt rate limits, the reminder robot, or anything else useful.
The emails used to include this which explains why in your situation:
No idea why they stopped including that paragraph.
Yeah, that would have been helpful!
Interesting. I never get these emails so I don't have anything to compare, but
https://github.com/letsencrypt/boulder/blob/master/data/production-email.template
... suggests this email template hasn't changed for many years and still contains the text Ryan mentioned. If yours is missing maybe I should prod somebody about that.
Looks like that email format is no longer used, my latest renewal reminder looked like this:
Hello,
Your certificate (or certificates) for the names listed below will expire in 19 days (on 09 Jun 19 14:27 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors.
We recommend renewing certificates automatically when they have a third of their
total lifetime left. For Let's Encrypt's current 90-day certificates, that means
renewing 30 days before expiration. See
https://letsencrypt.org/docs/integration-guide/ for details.
[list of domains cut]
For any questions or support, please visit https://community.letsencrypt.org/. Unfortunately, we can't provide support by email.
If you are receiving this email in error, unsubscribe at http://mandrillapp.com/track/unsub.php?u=%5B...]
You may need to update your client to the latest version in case it is still using the deprecated TLS-SNI-01 validation method. https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209
Step-by-step instructions for updating Certbot are here: https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210
Regards,
The Let's Encrypt Team
I’ve (mostly) stopped bothering with altnames on certificates - they were just a hack to mitigate the fee structure for commercial CAs.
Now that I’m using LetsEncrypt for almost everything, I just get a whole certificate for each domain and let SNI serve the right one out to a client, but how easy this is depends on what saw you use (haproxy works for me, but ymmv as always).
I guess this can also help to not tell people that visit http://www.domain1.com that you also host http://www.domain2.com which might matter to some people.
SANs (which appear in PKIX in 1999 but before that there isn't really any standard for how this works, shoving an FQDN into the X.509 Common Name RDN is definitely a hack) aren't a hack to mitigate the fee structure. If you just wanted such a hack you could (but please don't) have done it already by just documenting a new way to interpret multiple DNs in X.509. There are (historical, please do not attempt at home) examples of this being tried.
SANs put the machine readable things (IP addresses, DNS names, email addresses) into a machine readable field defined in a sane way for the purpose, e.g. an IPv4 address is 4 bytes, so you can't have an ipAddress SAN for 100.200.300.400 whereas writing that in the Common Name of an X.509 cert "works" fine even though it's nonsense.
A more actionable example might be DNS where SAN dnsNames are explicitly the "punycode" ASCII DNS name [except the first label might be replaced by an asterisk, the wildcard], and you literally can't write emoji, Cyrillic, Linear B or whatever else might seem fun, because the ASN.1 definition doesn't allow for it. And so when IDNs became a thing this all just magically worked, whereas over in the X.509 Common Name it continues to cause untold chaos, even today in languages like Python, because there's nothing stopping them writing whatever they think you wanted and then good luck if any particular software will agree with that.
Today popular software including Firefox and Chrome only looks at SANs (in the Web PKI). A certificate you think of as "Not having altnames" actually has exactly one SAN, and the Common Name is just filled out with some textual representation of that SAN as a courtesy. Well written software isn't looking at CN, it's for humans only.
The "alternative" doesn't mean in the sense of an alias, but in the sense that these names are the Internet's alternative to the X.500 series directory system for which X.509 was conceived. Since the X.500 directory system never really happened this "alternative" is now in reality the only game in town.
The other replies here seem correct, but just to be thorough, here is the cert it's warning you about: https://crt.sh/?id=1250961232