No longer getting expiration emails

I am no longer receiving email notifications about cert expiration.

Updating manually using getssl. Have 3 sites currently.

1 Like

I find that “~/.getssl/getssl.cfg” has a line “#ACCOUNT_EMAIL=”.

Clearly it is commented out. Is this the line I should edit to enable expiration email notices, once certs are renewed? Can this be a “per domain” email, that is different in each domains config so as to send email to a different email address?

1 Like

Hi @joea,

I believe your idea should work per Expiration Emails - Let's Encrypt

However, you can change the email address on your account, which effectively re-subscribes you. Many common email services treat yourname+1@example.com the same as yourname@example.com . So if you update your email address to yourname+1@example.com , you can start getting expiry mail again. With Certbot, use:

certbot update_account --email yourname+1@example.com

2 Likes

I did not find that link, viewed earlier, to be of any real assistance as seemed to refer to certbot.

Did find a more direct description of that config parameter via some diligent searching.

In any case, I attempt to enter a value as see what transpires.

2 Likes

I’m interested too, keep us updated!

2 Likes

I do not know of a way to test the email subscription. Seems there should be a way to do that. The link provided does make reference to Mandrill and ways to unsubscribe, but there seems to be nothing fathomable beyond that.

I did change the setting in the config file and ran getssl to check certs, but no idea if that is supposed to
register the address or if some confirmation email is to be expected.

If someone could provide more details on how to check “account” features that might help a great deal.

1 Like

@joea Can you attempt re-issuance and post the domain you’re re-issuing for please? I’ll check the logs and the Mailchimp setup to verify you’re listed in there.

2 Likes

Done. www.nuckenfutz.com/

Read nothing into the site name, of course.

I guess I should have attempted a PM.

1 Like

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 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?

3 Likes

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.

4 Likes

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.

2 Likes

@_az

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.

2 Likes

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.