Provide mechanism to set/update account contact mailto address

[mhoran]

According to https://letsencrypt.org/docs/expiration-emails/, if a contact mailto address is set at account registration (or updated to include a mailto address at some later point), Let's Encrypt will provide email notifications of expiry at 20, 10 and 1 days to expiry.

Due to faulty configuration my part I've had a certificate expire without realizing it. This seems like a great feature provided by Let's Encrypt and it'd be great if acme-client could expose the mechanism required to set/update the contact mailto address so that this feature works for acme-client users.

Here's the relevant bits in certbot that update the registration with the contact mailto address. Here's the relevant bit of the spec (though it does not detail the Let's Encrypt specific behavior).

[cpu]

hi @mhoran, +1 for supporting this. It's an important feature Let's Encrypt relies on to update subscribers about certificate expiration and other important subscriber agreement changes.

Here's the relevant bits in certbot that update the registration with the contact mailto address. Here's the relevant bit of the spec (though it does not detail the Let's Encrypt specific behavior).

Quick clarification: The https://letsencrypt.github.io/acme-spec/ repo is deprecated. The proper home is with the IETF now at https://github.com/ietf-wg-acme/acme. Section 6.3 describes new accounts and updates to accounts (e.g. to add a contact to an already created account).

(though it does not detail the Let's Encrypt specific behavior).

We maintain a list of divergences between the specification and our implementation as it evolves.

Hope this helps!

[kristapsdz]

It would be great if you were to read the README, which says, Feature requests will be ignored unless joined by a patch.

[mhoran]

I had considered submitting a patch but didn't feel comfortable contributing on my own. Now I definitely don't feel comfortable contributing.

Perhaps someone else will see this and submit a patch.

[kristapsdz]

@mhoran, that's not fair and outright unkind. I write this software, and all software on this account, with my own hands, in my own time. You're making a request of my time when you won't even take your own time to help out. I understand thinking that this is important, and maybe it is to you, but a responsibility of participating in the open source community is contributing.

This particular feature is not useful to most users of acme-client, and also not to me. Not because it's bad, but if you're running acme-client on a cronjob, as you should be, there's no reason to be contacted.

[mhoran]

I apologize that you interpreted my response as being unkind; that is also how I interpreted your response. I respect your time and understand that this issue is not a priority. I also admit that I overlooked this aspect of the README, though your wording implied that I did not take the time to familiarize myself with your project whatsoever, which is untrue. This is why I responded in kind.

Re: not being a useful feature, I am running acme-client via cron and have set it up as recommended. Yet, I received no error or notification that certificate renewal was erroring, until a user of one of my sites reported an expired certificate. As it turns out, acme-client was failing to re-verify a domain due to misconfigured nginx for the acme-challenge. I received no notification from acme-client of this failure, yet if I received a notification from Let's Encrypt I would have known.

So I'd argue this is a useful feature, especially for the additional reasons provided by @cpu (important subscriber agreement changes, etc.)

Perhaps I will attempt to patch this myself after all. But I want you to understand my above statement: your response and assumption that I did not appreciate your time nor take the time to familiarize myself with your project is not true. I appreciate your efforts and the efforts of all open source maintainers. It's a thankless job, and lots of people take advantage of maintainers. Trust that I am not one of them.

Thanks.

[kristapsdz]

@mhoran, understood. How do you run acme-client? If it's in a cron-job, it should report errors on stderr and these should be mailed to you by cron. If it's silent in this class of failure, then that's certainly a bug that must be fixed! If I'm not mistaken, this kind of error would trigger the following:

warnx("%s: bad response", chng->uri);

Do you see this in your logs?

[mhoran]

I just checked my logs, but I think any error from the time of this issue must have rotated through by now. acme-client ultimately runs via cron, but the FreeBSD port uses FreeBSD's "periodic" functionality to schedule acme-client.

Looking at the scripts, nothing is redirecting stderr or stdout to /dev/null, so I should see something in my weekly "periodic" mail. There is also a note that should be printed stating that this script is running; but I don't recall ever seeing this.

Given my certs are no longer expiring, I'm fairly certain that acme-client is running on a weekly basis. I am concerned, however, that I've never seen anything in my weekly mail. I'll have to see what happens this week and will let you know if anything looks awry.

Thanks!