I've suggested this before, but now that ARI has come along a bit I wanted to formalize this in a feature request:
The volunteers on this forum get lots of requests about seemingly "false" warnings of the expiration mailer (1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and probably over a hundred threads more). We already have FAQ article for this in the forum and the renewal mailer also tries to explain the situation right in the mail:
The mailer simply doesn't detect renewed certificates when the set of FQDNs change, because that's the only thing it looks at. In the past there wasn't really much you could do about this: The ACME protocol had no formal concept of a renewal vs a new certificate. However, with ARI, ACME clients have the capability of telling the ACME server which certificates they have replaced, i.e. are no longer in use. This is useful information to the expiry mailer: We certainly don't need to mail a user about a certificate that has been marked as replaced, even if the FQDN set doesn't match.
From my point of view, ARI is now moderately stable (IIRC no huge changes are expected anymore) and Let's Encrypt has already started using ARI by exempting ARI conforming renewals from all rate limits. My feature request is to go the next step and utilize ARI to improve the renewal mailer. Of course this will only take full effect once all major clients support ARI, but I suspect that over time more and more clients will support ARI. Enhancing ARI with more "benefits" also improves the incentive for client authors to implement the extended functionality.
Actually that's not fully correct, the expiration mailer already checks that a certificate has not been revoked first. Sounds like "and has not been replaced" would simply be another condition here?
I'm curious how many clients will set "replaces" for a cert when the SAN set changes. Will a client consider a cert for www.example.com and example.com a renewal of a cert that had only example.com? What about a.com, b.com, c.com for a cert that had only a.com?
I need to reread the ARI spec, but does it permit specifying multiple values in the "replaces" field? If not, it's not possible to consolidate certificates in terms of ARI recordkeeping.
Certbot has this thing unofficially called "lineages" which have their own certificate name.. And one can change the list of hostnames, while keep using the same certificate name/lineage. Heck, I think you can even keep using the same private key while changing all the contents of the SAN extension. I'd say if you update the same lineage, no matter which changes to the SAN, Certbot could/should (perhaps a manual override or opt-in..?) set the certificate as replaced IMO.
That's up to the client of course, but for example certbot has a concept of "expanding" a certificate (--expand). So certbot knows that it will replace a previous certificate with a one that covers a different set of FQDNs. And while certbot doesn't yet support ARI, my imagination was that many clients work in the same way: If your ACME client issues a new certificate that's supposed to be a renewal, your client somehow has to know about the old cert already, even if the renewal changed the FQDN set.
No, you can only specify a single certificate that's been replaced by the newer one.
If one replaces two certs, one with example.com and another one with www.example.com, with a single cert for example.com as well as www.example.com, it stands to reason one would like to mark both the previous certs as "replaced".
Consolidation does not appear to be something that we encounter frequently on these forums. It also did not appear relevant enough for LE to consider it when designing ARI (in particular, they need the replaced field for emergency revocations & rate limits). So if it's not deemed important enough for these use cases, I wouldn't deem it important enough for the renewal mailer either.
If it's deemed common enough, the entire ARI spec should be updated. I can't see an argument that says "it's fine for mission-critical use-cases, but it's not fine for the expiration mailer".
PS: I also don't see the issue here. Yes, there may be more or less rare edge cases where the "replaces" field isn't sufficient and there will be a certificate that is in fact replaced, but couldn't be marked as such. But where's the problem with that? In such a case, we might still have cases where the renewal mailer sends mails when it doesn't need to. But that's the status quo. Not implementing this means that the renewal mailer has a high "false positive" rate. Implementing this means that the "false positive" rate has the potential to drop dramatically, but it won't drop to zero. But who says that we need the mailer to be absolutely perfect with no false positives? It's not, currently, so why does it need to be now?
But, many of the topics you link to in the topic are cases of multiple SANs coming together on a single cert.
Why would the entire spec have to be updated? I envision changing a string to an array of strings, and some verbiage that says something to the effect of how to handle multiple replaces values (and if 1 is invalid, etc). But the whole spec? Nah.
It seems like a needless limitation that will have people asking questions "How do I replace multiple certs with 1?"
I actually think this is quite a common case. People start with a few domains, then later realize they need to consolidate to avoid LE rate limits. Rate limits imposed by LE motivate cert consolidation (despite not being best practice, so I think a spec drafted by LE should accommodate that.
When I said "updating the entire spec" that's what I meant. Changing even a single word in the spec mandates a new draft (ie -05), which is "updating the entire spec". However, changing implementations can be done without writing a new draft, even if it incurs logic changes (as long as those are not in violation of the spec).
In my experience in helping people in this community, most multiple-to-one consolidations I've seen have been: "oops, I screwed up, what hostnames should be on my cert?" I agree though, @mholt, a cert with any other name is... a different cert? To me this comes down to the "identity" of a cert, possibly its private key? Since "renewal certs" are generational (duplicates in the sense of the SAN set, which is what Let's Encrypt considers a cert's identity per the condition of the expiration notices), they typically, but not by requirement, have different keys from their forebears. This seems to be an identity crisis.
Also worth noting that draft-04 says that the certificate referenced in the "replaces" field should overlap with at least one identifier (domain name), and that if it doesn't then it should reject the request. I don't know if some client authors might not quite realize the implications there, that if one is updating all the names for the "same" certificate that it's not allowed to send it as a "replaces", even if (for whatever reason) the client configuration is thinking of them as the same cert as the old one that had entirely different names.
Both you and @griffin make good points, and now, as a client author, my head is spinning.
Current ARI draft cannot support consolidating certificates, but also has problems expressing the opposite: if an old cert has SANs A and B, being replaced by two new certs A and B (separate), only one can say that it is a replacement.
I think that's less of an issue, in that CAs probably don't care as much about which cert was replaced, just that the prior cert was replaced. So if it's replaced, they can revoke without as many worries about taking down a subscriber's site (assuming that subscribers can install certificates reasonably quickly after acquiring them), or can (as suggested here) not send reminders or alerts about it.
