No longer getting expiration emails

So, nothing doing? From the docs: “If you provide an email address to Let’s Encrypt when you create your account, we’ll automatically send you expiry notices when your certificate is coming up for renewal.”

Just what does that mean? When I created the account to access, for instance, this site? When I change that will it re-register for notifications?

If so that seems to conflict with what I understood the parameter in the getssl.cfg was for.

Or, must the two email addresses agree?

And, how can I test this without having to wait for expiry date to arrive?

Oh, and apparently the email address parsing in preferences does not accept the “us” domain.

1 Like

Let’s Encrypt has a notion of a Let’s Encrypt account that’s used by your client application to request certificates. It’s completely separate from a community forum account. The Let’s Encrypt account doesn’t have a password (rather, an encryption key which is stored on disk by your client application), and you can’t log in to it or anything.

1 Like

Thanks. So how do I tickle the fancy of this notion? I’m using getssl script to do the dirty work for me and have added an email address in the getssl.cfg file.

Re ran one renewal yesterday after that as previously suggested. But only thought to actually install that cert today.

How can I test that notifications will now work, or not work?

Or is that a question for the getssl crowd? (no fair just sending me away now . . .)

1 Like

@Phil_LE are you able to look this up? My recollection is that there’s no way for end users to check via an API.

1 Like

@ezekiel or @jillian Could either of you check this please?

1 Like

The “account” (as described by @schoen ) used to renew the domain listed above does NOT have an email contact set. Thinking of options here… if getssl doesn’t include the functionality to change the registration contact, you might be able to use a client that does, or submit a bug with getssl?


That may be a great clue. In prior cert generations the account email was commented out. I have since entered one and thought I had run the script again with option to renew without regard to expiration.

Perhaps I should do that again and someone could re-check, if there is no way for me to check on my own?

I’m assuming the act of generating a renewal will register an email and it does not have to actually be installed. Perhaps once a cert is generated a new address cannot be registered and the cert must be generated “from scratch”?

1 Like

The way getssl is written, it is incapable of adding an email once the ACCOUNT_KEY already exists. Renewal won’t help, even if you add an ACCOUNT_EMAIL.

If you change both ACCOUNT_KEY and ACCOUNT_EMAIL in one go, and then renew a certificate, your new certificate should be attached to an email address and you should get reminders.


The certificate itself is not really important, the “account” is the important part. Generating/renewing certificates will not inherently tell the API about your contact information, your client needs to support the functionality, as Certbot does.



OK, thanks. I did drop a comment over at github, just now. Perhaps they might look into adding that functionality.

I’ll give your observations a work out pretty soon.


No response at github/getssl, so . . . will deleting account.key and doing an update do the trick? I suppose that will invalidate all current certificates as well?

OK, so. Renaming account.key and attempt and running getssl gives me this noise:

"Registering account
getssl: Error registering account … “Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https”

There is no reponse as yet to my earlier query at getssl, so I doubt I would get any assistance with this either.

I am using the default staging server, but did attempt to use the production servers, with either acme-v01 and acme-v02 specified as the CA.

Seems odd that getssl would create scripts with v01 in it, as it is claimed to be v02 compliant. Or is that not the case?

Also, “In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.”

Last I checked, it is not yet November 2019.

OK, so after looking at some other products, I found the correct servers to use and patched them into my base script. Same error.

Twas then I found I had added a CA in each of the domain scripts, for some reason, and that was overriding my base entry apparently.

So now, I can get the script to run. and it generated a new account.key file.

However I have no idea if it actually registered an email address for the account.

They’re running periodic brownouts before November.


I took a quick look at the server logs for requests coming from what I believe is your IP address (ending in .251). Over the past 7d I can see a fair number of ACME v1 new registration requests that include a contact email but unfortunately none of them look to have succeeded.

One batch received replies like:

"Error":"409 :: malformed :: Registration key is already in use"

indicating that the ACME client is trying to create a new registration but using the same public key as an existing registration.

The other batch received replies like:

"Error":"403 :: unauthorized :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See for details."

As @mnordhoff mentioned (thanks!) that batch is a result of our rolling brownouts.

Can you perhaps try again now that the most recent brown-out has ended? I can check the logs again afterwards to confirm if there was a successful new account registration with an updated contact.

1 Like

@cpu I ran a bit earlier and it appears to have re-registered. Should have been a version 2 as I altered the script to point to a v2 CA.

Did not install the new cert. Did not get any email at the address I attempted to register. Perhaps not supposed to get a notice there upon registration?

1 Like

Hmm. You’ll have to help me out finding the logs in that case. I searched for issuances for over the past 7d and only found the ACME v1 requests. Can you share the email address you used, or the egress IP address of the machine you ran the ACME client on?

That’s correct, there is no email sent to the contact address for new account creation.

1 Like

I’ll just wait to see if I get a notice and take it up again if I don’t.

1 Like

Sounds good. :crossed_fingers:

1 Like

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