Let's encrypt is sending wrong domains to random email addresses


#1

The domain lekkeretenmaken.nl is expiring. The email address x@x.x is receiving the email with the following domains:

++++++
Your certificate (or certificates) for the names listed below will expire in
19 days (on 03 Jul 18 09:44 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.

1energiezuinighuis.nl
lekkeretenmaken.nl
simondev.nl
www.lekkeretenmaken.nl
+++++

The domains simondev.nl 1energiezuinighuis.nl are not his domains. The other domains are requested with email adres y@y.y

We use a single letsencrypt “account” to generate certificates.

How can this happen and how are we going to prevent this from happening?


#2

Hi @rickjanssen,

I don’t see the associated certificate. Is it possible that this is a reminder related to a staging certificate rather than a production certificate? Staging certificates also generate reminder e-mails, but their expiry is usually of no consequence because they were already not accepted by browsers.


#3

Hi @schoen

No, its not from staging. Note that only www.lekkeretenmaken.nl and lekkeretenmaken.nl are his domains. The problem is that the other two are also included in this email. Althoug they are not in his certificate. You can fetch the cert on his website www.lekkeretenmaken.nl

crt.sh https://crt.sh/?q=8cf9603b87c9f5df14b58a75887391765409f460


#4

I see that certificate, but I don’t believe that that’s the certificate concerning which this reminder was sent, both because the set of names concerned is different and because the cited expiration date is different. Could you please post the entire expiration warning e-mail? (I don’t care about the recipient’s e-mail address, just the surrounding text sent from Let’s Encrypt.)

@jsha @cpu, is there an easy way that you, or the general public, could look up staging certificates to test my hypothesis that this warning may have been sent in relation to a staging certificate rather than a production certificate?


#5

Like @schoen I cannot find any record of this certificate at crt.sh.

However, I can tell this e-mail is definitely supposed to be from production. The OP quotes the introductory text:

But I recieved a staging expiry notice on June 10th, and it had this introductory text in place of the above:

You issued a testing cert (not a live one) from Let’s Encrypt staging
environment. This mail takes the place of what would normally be a renewal
reminder, but instead is demonstrating delivery of renewal notices. Have a nice
day!

If the OP’s email does in fact pertain to the staging server, it was sent with the production e-mail template, which could definitely be confusing.


#6

Staging certs have two SCTs, but it seems that neither log is on the internet. Maybe that can change :slight_smile: ?


#7

This certificate, for lekkeretenmaken.nl and www.lekkeretenmaken.nl, does expire at 09:44:

https://crt.sh/?id=381540411

I guess when you get an email about multiple certificates expiring at about the same time, it picks the timestamp from one of them.


#8

Hi The full email:

Hello,

Your certificate (or certificates) for the names listed below will expire in
19 days (on 03 Jul 18 09:44 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.

1energiezuinighuis.nl
lekkeretenmaken.nl
simondev.nl
www.lekkeretenmaken.nl

For any questions or support, please visit https://community.letsencrypt.org/.
Unfortunately, we can't provide support by email.

For details about when we send these emails, please visit
https://letsencrypt.org/docs/expiration-emails/. In particular, note
that this reminder email is still sent if you've obtained a slightly
different certificate by adding or removing names. If you've replaced
this certificate with a newer one that covers more or fewer names than
the list above, you may be able to ignore this message.

If you want to stop receiving all email from this address, click
htp://mandrillapp-dis.com/track/unsub.php?u=yyyyyyyy&id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(Warning: this is a one-click action that cannot be undone)

Regards,
The Let's Encrypt Team

I want to remind again that there should not be send a email to x@x.x because the domain simondev.nl and 1energiezuinighuis.nl are not x@x.x his domeins. The domains are from y@y.y.

X and Y are both using the same account created by let’s encrypt for this server.


#9

Email addresses are associated with accounts, though. Not individual certificates. If you’re using one account, its email address(es) will get warnings about all of its certificates.

You might have to start using multiple accounts, or direct the emails to a central help desk or something.


#10

Hi @rickjanssen

who is “We”? Do “We” has two customers - one x@x.x (“his” with lekkeretenmaken.nl) and y@y.y with the other two domains?

If you are using a single letsencrypt-account to manage these 4 domains, then the mail is normal.


#11

Ok, there is the answer:

X and Y are both using the same account created by let’s encrypt for this server.

Then one mail is normal.


#12

If this is the case, then I’m completely confused by the integration guide stating I should use one single account per server. Besides that, I can’t create more than 5 accounts per server since the rate-limits are so tight.

I will change all accounts email addresses to my own email adres. Will this cause all certificate warnings to be send to me, despite them being requested by me with a different email address?

Since we check the certificate expiration date our self, can we just disable the whole warning at all?

@JuergenAuer We is the company I work for. X and Y are customers who have nothing in common, except us.


#13

The --email option is completely ignored except with certbot register or the very first time that you run another command that requires creating a Let’s Encrypt account. So the subsequent certificates are requested with the original account, which continues to be associated with the original e-mail address.


#14

Yes, if you update the account. I believe you can do that with certbot register.

Thanks for reading the integration guide! Can you tell us more about the type of integration you’re running? We may be able to provide some advice to avoid other pitfalls.

Here’s the most relevant part for you:

Who is the Subscriber
Our CPS and Subscriber Agreement indicate that the Subscriber is whoever holds the private key for a certificate. For hosting providers, that’s the provider, not the provider’s customer.
The upshot of this is that, if you are a hosting provider, you do not need to send us your customers’ email addresses or get them to agree to our Subscriber Agreement.


#15

Thanks. Then you can use one account (+ a lot of server) for all customers. I create also certificates for some of my customers. But they don’t get a notification mail, there I use only my own adress.

PS: I am using letsencrypt-main@example.com (productive) and letsencrypt-stage@example.com (testsystem).


#16

Hi,

I’ve implemented a one click solution in our hosting panel to activate HTTPS and request a certificate from Let’s Encrypt.

I see the part of the subscriber. I was not aware of this, I might not have linked subscriber to the warning mails. It was pretty clear indeed " If you’re a hosting provider, those notifications should go to you rather than a customer"

We currently have one account per server. I would like to reduce that to 1 account for the whole company. However, the ratelimits are too tight for that. Is it possible to have these ratelimits lifted? We currently have a lot of domains we want to activate but we’ve been hitting the rate limit some times, the failed authorizations for example. I’ve requested a rate limit lift for our IP range and had one of the account keys noted. She told me she can’t do that for IP ranges, but only per account. I would like to put every server in our control under one single account and, if possible, move or re-request all certificates to that one account.

I really have to go to sleep now, its 1 AM here and I’ve had some hectic nights due to a poweroutage. I’ll read the responses tomorrow. Thanks for looking into this! Much appreciated :slight_smile:


#17

Cool! Which hosting panel is that? Are you using an existing client, or did you roll your own?

Putting all of your servers under one account is a good idea, and we recommend that. Note one pitfall we’ve seen similar hosting providers run into: If you have lots of frontends, it’s easy to wind up in a situation where they are all requesting from Let’s Encrypt at exactly the same time (e.g. midnight). It’s important to set up your crontabs on each machine to refresh at a different time, to spread out your load. If you really have a lot of frontends (thousands), you may also want to add some coordination so you can throttle issuance rate.

Most of our most relevant rate limits are not per-account, but per-domain or per-hostname. For instance, the failed authorizations rate limit is per-hostname. If you’re hitting that, it will only affect the one hostname that’s failing repeatedly. It won’t affect your other hostnames. In other words, this rate limit shouldn’t be a barrier to consolidating your issuance.


#18

Thanks so much for jumping into this conversation, Jsha!

@rickjanssen as for your original question, are you using Plesk? If so, this is a known bug that has been fixed in later versions. https://github.com/plesk/letsencrypt-plesk/issues/91


#19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.