We have a few sites on one Cloudways DO server that use Let's Encrypt SSL, which automatically registers certificates through the API and sends out renewals on a schedule. It's generally brilliant, and I have to send a massive thanks for making what was once an annoying mess, to a simple, clean, and easy process.
However, an issue arose recently.
An application on that server was closed down 6 weeks ago. It was completely deleted.
6 weeks later a client of mine forwards me an email from expiry@letsencrypt.org notifying them of certificate expiry for the domain that was deleted.
The issue is that this client wasn't associated with that application whatsoever. They received this email out of the blue for a completely different website.
And the expiry notification was sent to their personal email address, which wasn't used on that application at all, and (I think) not even on their own website. All registrations are with my work email address.
I've notified Cloudways, and they are reluctant to take responsibility or even investigate the cause. They suggest that because the email came from letsencrypt, I should contact you.
This isn't something I really cared too much about, until Cloudways refused to investigate. There's a good chance that it was human error; occam's razor. But with me being the only common point of contact here, and not believing I would have made any obvious mistakes like this, I don't think it was. I think it's an issue with Cloudways API coding/whatever that caused this anomoly.
The primary concern is that obviously there's a data leak issue. If that was my fault, great. I can deal with it. If not, then whatever caused it needs to be plugged.
I'm not familiar with "Cloudways", but it does seem that some providers don't correctly understand who the "subscriber" is supposed to be, and put in one of their clients' email addresses for an account when really it should be the provider themselves, leading to confusion when that client gets email that really should be addressed to the provider. (Or, in some other way, they mix up which accounts should get which email addresses.) Doesn't happen that often, but there are a couple stories around this forum of people being confused about why their provider chose a particular email address, sometimes leading to the wrong people getting notified.
The "official" guidance from Let's Encrypt is in the Integration Guide, "Who is the Subscriber", basically saying that the person who should be signed up should be the person who possesses the private key and is empowered to do something about it if there is a problem with automatic renewals or the like.
But without knowing a lot more about the provider, or how they've set up their ACME accounts and how they've selected what email addresses to put in them, I'm not sure that there's a lot that anyone here can do, or if there's much guidance that people can give you. It's possible that they're doing something "wrong", but if they're not interested in fixing it I don't know if you can make them. Or its possible that they're doing everything right, and someone just put a wrong email address on a form, in which case again I don't know what action should be taken (particularly if the applicable web site has been decommissioned).
There might be other people here more creative than I that have better ideas for you, though.
At some point, an ACME Client requested the Certificate(s) from LetsEncrypt.
The ACME Client which requested the Certificate was configured to create/use an account with the email address "yourclient@example.com". That ACME Client appears to have been used to obtain additional certificates for your other domains and clients.
There are at least two likely errors here:
You are running an ACME Client on the server yourself, configured it with your initial client's email as the Subscriber.
Cloudways is running an ACME Client and has configured it with your initial client's email as the Subscriber.
Generally speaking:
In an "Agency" setting or a Dedicated/Unmanaged Server setting, the "Subscriber" should be configured for your email as you manage the domain for your client. This holds true if you are running the ACME client or Cloudways is.
In a "Platform" setting or Shared Server setting, the "Subscriber" should be configured for the Cloudways admin email. In a Managed Server setting, the "Subscriber" would normally be the Cloudways admin, but might be yours as well.
You'll need to figure out how the Certificates are handled on that system and were provisioned for that domain.
If you installed an ACME Client like Certbot and run it yourself, the error was your fault and you need to either change the Account Email for LetsEncrypt or partition the certificates into different accounts.
1- You made an error and provided the wrong ssl_email param
2- Cloudways is recycling an ACME account multiple "Applications"
In the second scenario, this could be due to an error OR due to a design implementation on their system - wherein they recycle a previously established ACME email/account form your Cloudways account when you do not configure a second "Application" when a ssl_email param.
I'm not sure what you mean, sorry. The fact that the application was deleted isn't really the problem. It's that an expiry notification was sent to a subscriber for a domain that they weren't (or shouldnt have been) subscribed to.
Blockquote 1- You made an error and provided the wrong ssl_email param
2- Cloudways is recycling an ACME account multiple "Applications"
In the second scenario, this could be due to an error OR due to a design implementation on their system - wherein they recycle a previously established ACME email/account form your Cloudways account when you do not configure a second "Application" when a ssl_email param.
Yes, this second scenario sound more likely.
I do wonder if this particular client's application was the first one we installed on this server, and maybe mistakenly (or otherwise) I entered their email when registering the certificate. This would have been 2-3 years ago, so it's difficult to remember.
However, this client would then have been receiving all expiry notifications for all applications that use LE SSLs on that server. There are 9 other websites on that server.
Is there any possible relation between that subscriber and that expiring domain?
[yes, I'm looking at this from the completely opposite view]
I'm not thinking this is a random as it sounds.
@tehben You could use a tool like https://crt.sh for cert history for that domain. Perhaps the client was also getting certs some other way using their personal email. When the app was closed maybe they closed that down too. The cert history would show an unusual pattern of renewals.
This more likely happens with DNS Challenges but it is definitely not impossible for multiple clients to be getting certs.
The key part here, to me, is that those email expiry notifications are not tied to specific domains, nor to any FQDNs; They are tied to the account that created [all of] them.
And with such single account configs, the last email entry overwrites any/all the previous ones.
And since expiry emails are only used when a cert hasn't been renewed, it can be "configured" not as one would have expected for many months/years and one would never be the wiser - until it becomes needed/used and we get unexpected results. It doesn't mean that those results were incorrect.