Confused :: expiry warning for non-expiring certificate

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:
I received an incoming email from you.

It produced this output:
Your certificate (or certificates) for the names listed below will expire in 1 days (on 18 Jul 16 10:17 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors.

My operating system is (include version):
Linux / Ubuntu 16.04

My web server is (include version):
“MailInaBox” / Nginx 1.4.6

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):
yes (mailinabox)

MailInAbox reports a long lifetime on the certificate, which is backed up by examining the certificate using Google Chrome … so why the email?

TLS (SSL) certificate is signed & valid. The certificate expires in 77 days on 10/03/16.

As your new cert contains additional domains it is not recognised as a renewal of the old one.

Ok … is this a bug?

No, that’s the intended behaviour.

Ok, Cool …

So if I understand I’m getting emails that relate to a certificate that
essentially no longer exists?

Did I do something wrong?

Well the cert does still exist, it’s just that you don’t want it any more. Of course the system has no way of knowing if that’s the case or if it should have been renewed.

It might seem as though “obviously” if you have a cert for names A and B, and then later you ask for a cert for A, B, C that’s a replacement. And in the most trivial cases that’s true, but continue the thought experiment, what if you later ask for new certificates for A and separately for B, C. Is one of those still just a “replacement” and no expiry emails are needed ? Which one ?

In philosophy this line of thinking ends with the “Ship of Theseus problem” which you can read about in Ancient Greek books, or in a modern undergrad intro course, and so rather than wrestle with philosophical problems as old as civilisation itself Let’s Encrypt punts whenever the certificates aren’t for exactly the same names as before.

Maybe, some day, Let’s Encrypt will decide to tackle at least some easy cases like yours but maybe not. Meanwhile if you know which names are on certificates you do still care about, you can ignore emails that list other sets of names.

Well, it’s been more than 30 years since I was a computing undergrad, but from memory we didn’t do much with Ancient Greek - unless you count ‘prolog’, but what you seem to be saying is that if I add a new host name to my certificate from time to time, I can expect an email relative to each change (at some point) telling me that my certificate has expired, when really the certificate that my current certificate superseded is actually the one that’s expired ?

Just a thought from mere (non-Greek) mortal, if you were to issue certificates based on a non-domain related tag, when it came time to re-issue a certificate with more or fewer host names, referencing that tag would indicate whether it was a new object or an object to be ‘updated’ … (?)

In Theseus speak, stick one plank from the ship in a safe in the hold, such that it isn’t subject to being replaced. Then the presence of that plank indicates whether the ship is indeed still the same ship.

Incidentally, given MailInABox actively checks each certificate daily and updates automatically, I don’t actually want / need the emails … it there an easy way to disable email notifications?

A separate, permanent "certificate ID" that persists across renewals would seem like a lot of added complexity just to stop the occasional unnecessary expiration warning. This would be another thing clients and servers would have to keep track of, I think it wouldn't quite be worth it.

It's possible to omit the email address completely during registration. Whether the client used by Mail-in-a-Box supports this is a different question. Alternatively, it's possible to unsubscribe from any email Let's Encrypt sends. Note that this is currently implemented as a global "don't send mail to this address".

A separate, permanent "certificate ID" that persists across renewals would seem like a lot of added complexity just to stop the occasional unnecessary expiration warning. This would be another thing clients and servers would have to keep track of, I think it wouldn't quite be worth it.

Mmm, I was actually thinking in terms of you guys having to maintain many x the number of certificates than were actually 'live', but if people rarely update certificates then I guess in this instance it's not an issue. I've used the unsubscribe option so hopefully I can rely on MailInABox to do my monitoring and updates.

Everything else aside, your collection of keys in whatever form it's held would constitute a database, and if you follow database good practice (i.e. EF Codd, Rule#2) or indeed if you store the keys in a database, then this unique reference will already exist and be maintained for you - so the complexity will be "null" .. and with regards to unsolvable paradoxes;

"If the problem you're working on seems to be unsolvable, then the chances are you're trying to solve the wrong problem."


As a CA, there's really no concept of a certificate being "live" that would allow you to "forget" or "stop to maintain" a certificate. Every certificate file is different after renewal, independent of whether the domains change or not. Auditing requirements would force you to store the certificate permanently either way, and OCSP responses would have to be signed until some time after expiry as well. The only application of something like this permanent tag would indeed be expiration notices.

Mmm, I was sort of assuming there would be a similar issue with regards to revoking certificates, but if there is no revoke facility I guess that won’t be a problem at the moment … although I can’t help thinking at some point this might change, either because people want it or because we get some sort of regulatory requirement … at which point you’re back to Theseus again.

Revocation is possible, but it’s based on individual certificates (independent of whether we’re talking about OCSP, CRLs or the way Let’s Encrypt implemented it in ACME, so the abstraction Let’s Encrypt has chosen matches other protocols). You could have a private key compromise, and only want to revoke one certificate that’s part of this hypothetical “permanent tag”, while continuing to use the tag for the next certificate (with a new private key - which is the default for any certbot renewal), so revocation based on this tag would not make sense.

If you revoke “a certificate”, it’s that specific certificate that gets added to the CRL, so sure, you’ve no need for a tag. However, because you don’t have a tag, you may have any number of previous certificates that may have been issued, then superseded but not yet expired. So as a result of the non-tagged model, you may have any number of certificates that probably need to be added to the CRL. As a “user”, at this particular point in time, I don’t know how many certificates have been issued on my domain or what they are (bar the one that’s currently active on the site). The same could be true for anyone using a scripted system. So if I had a compromise today, how how would I go about recovering a list of certificates to revoke? (given I can only see the one in my live folder?)

I would question whether "I want to revoke certificate X" always equals "I want to revoke all certificate instances of permanent tag X". That would seem like a bad assumption to make, especially if only one specific private key was compromised (again, the private key changes for every renewal).

What you're describing is a client-specific problem. There's no reason why clients could not manage this permanent tag for you. In fact, that's what certbot does with the lineage concept (i.e. each directory in /etc/letsencrypt/[live|archive] is a lineage). You can "recover" each certificate you've used previously by looking at the /etc/letsencrypt/archive/ folder of your lineage, it keeps track of each certificate and private key you've used in the past, and you can revoke each separately if you need to. It would also be perfectly possible to add a "revoke lineage" subcommand to do that automatically, but I imagine there's not too much demand for that feature as revocation is not something you need every other day, and typically you've got two active certificates at the most, so running certbot revoke twice is acceptable.

You can also look at Certificate Transparency logs (for example via to check all active certificates for a particular domain.

I would argue that the protocol is the wrong place to add this functionality, as it would make assumptions about your particular use-case, which is something a client could do in a way more flexible manner.

Mmm, is a very useful tool, I’ve not come across it before, tvm. Looking in my “archive” folder, I have just the one folder for my domain, and one keyset within that folder … and the entry in “live” is a symbolic link to this entry … so in this instance, although shows two keys as active, as far as I can see, I only have the one on my system.

Anyway, I think I’m starting to ‘get it’, would this be possible;

  • Attacker breaches system, copies /etc/letsencrypt, recreates, then requests a new key
  • At this point there are two valid keys in circulation, user’s system knows about “one”
  • Attacker tells user he’s been cracked
  • User secures his system, revokes his key and requests a new one, then relaunches his site on the new key
  • User thinks he’s safe, Attacker is left with a working key until it expires

And the “only” way to spot this would be to check against for multiple certificates ??

(incidentally, doesn’t seem to list the host-names for a given entry - is there a way to list host names against each certificate via or similar?)

Sounds like your previous certificates were created on another system, or /etc/letsencrypt was deleted at some point. certbot would've kept the old certificates and keys otherwise.

You've stumbled across a problem with the Domain Validation system in general - once your system is compromised, an attacker can issue certificates for your domains. You would not even need to have been using Let's Encrypt prior to the breach, and the attacker is not limited to using Let's Encrypt either, there are plenty of other CAs who'd be willing to issue Domain Validation certificates to anyone who has sufficient control over the web server. So yes, even if we completely ignore Let's Encrypt, the question of this permanent tag, etc., Certificate Transparency (through something like would be the only way to monitor your domains for these kinds of misissuances.

Oh, and just in case you thought it couldn't get any worse: Certificate Transparency is currently a voluntary thing, and many CAs don't submit their certificates to log servers (Let's Encrypt does), so if the attacker picks a CA that doesn't support Certificate Transparency, you probably won't notice anything. On the bright side, there's a good chance browser vendors will start enforcing Certificate Transparency somewhere within the next couple of years. :grimacing:

It's a bid hidden, you have to click through to the actual certificate and look at the Subject Alternative Name fields. For example, starting with the search results, you'd click one of the links in the "Not Before" column, and then look at the X509v3 Subject Alternative Name: fields, which would list all domains on that certificate.

Ok, I think I'm "there" .. :slight_smile:

Is there a required use-case that would defeat denying requests for overlapping certificates? (other than to replace / automatically revoke previous keys?)

.. and when will we see the LetsEncrypt control panel to replace .. :wink:

It's a bid hidden, you have to click through to the actual certificate and look at the Subject Alternative Name fields. For example, starting with the search results, you'd click one of the links in the "Not Before" column, and then look at the X509v3 Subject Alternative Name: fields, which would list all domains on that certificate.

Interesting, even with your instructions I still seem unable to see the names ... (there doesn't appear to be a Subject Alternative Name field(s)) ...

Let's rephrase the question: Is there a reason not to support that? It seems to me this would a) either prevent you from getting any certificates through Let's Encrypt for your domain in case you lose your account key or b) be easy to bypass if it's a per-account thing, by just creating a new ACME account (which the attacker could easily do). Any protection this might offer would still be effectively useless because the attacker could go through any other CA (even free ones such as StartCom or WoSign, if cost is an argument).

There's really no way around monitoring Certificate Transparency if you're worried about misissuance.

Hmm, that's odd. Historically, the Common Name field was also used to include the domain, but IIRC the Baseline Requirements state that the domain would have to be included as a Subject Alt Name anyway (might be mistaken, though). Could you post the link to that particular certificate?

Mmm, if a domain (host) could have only one active certificate, the question “are there other certificates out there being used to counterfeit my site” becomes moot once you have revoked what you have and re-issued it.

Opening another ACME account or using another CA does them no good without access to the domain’s DNS controller, so I’m not sure I understand what you’re saying. (unless you can get a certificate through without a successful callback to the ‘A’ record listed against the host?)

Given the apparent increase in security this would provide, “do you need an overlap” seems like a valid question. All you need is a control panel for revoking / re-issuing keys and lost keys etc become a non-issue. Indeed the situation I find myself in now (although not critical for me) with two issued keys and no record of one of them, sort of hi-lights a weakness of the current mechanism that could (potentially) be addressed.

Link is