True, the expiry mailer can’t be all things to all people. You can’t guess whether a certificate matters or not without actually getting in the user’s head.
If it comes down to a choice, I think that the mailer should cater to the most common use cases. The “I got an incorrect expiry reminder for a certificate which I expanded” is a daily thread here.
I rely on monitoring every SSL endpoint rather than looking at the emails. There’s no room for interpretation that way because you only watch the certificates actually in-use.
I think doing exactly that is fairly common. Certificate fingerprints are a thing, which are just a hash over the entire DER-encoded certificate.
Your browser shows it in its certificate UI, and OpenSSL exposes it as well:
$ openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -fingerprint -sha256
Boulder stores and queries the fingerprint already, so I don’t think it’d be a big burden on them to change the email template to include a serial and/or fingerprint, if they wanted to.
I just don’t really rate this method of monitoring. Look at the dates on your real endpoints, not the dates of possibly stale and unused certificates in some remote database. The advice on the expiration email page suggests as much:
If you check the certificate currently running on your website, and it shows the correct date, no further action is needed.
That said, if the mailer isn’t going to get a major facelift any time soon, including the serial gets my vote. Things might be a bit tricky if there’s multiple duplicative certificates expiring, though.