Update ToS agreement verification logic when ACME protocol is clarified

[rgl]

Currently acmetool asks for UniqueID: "acme-agreement:" + e.URI (or looks for the anwser) to TOS agreement, but why isn't there a way to auto accept the TOS (e.g. for use in a cron job)?

[icb-]

You can create a response file that states you agree to a particular version of the Subscriber Agreement. A blanket "I accept any agreement you present to me" flag sounds like a bad idea, particularly for non-interactive modes.

[petercolberg]

Let’s Encrypt will send a notice to the email specified upon registration in advance of a subscriber agreement update. The notification for version 1.0.1, effective August 1, 2016 was sent at the beginning of July, which was sufficient time to update the response file (after actually reading the agreement).

[rgl]

For me, its an annoyance to manually edit the response file or to manually run acmetool just to accept the new TOS. Thats not really an install and forget about certificates maintenance that I'm looking for. I guess I can automate this, but having some kind of flag on acmetool would be easier.

I understand what you guys are saying about automatically accepting the TOS, but look it this way. When Let's Encrypt sends me a TOS update notification by email, I would read it, and If I'm not OK with the TOS, I would have to uninstall acmetool and replace all the certificates with something else. But If I'm OK, there is nothing else to do. Sure, the notification email could have been lost or I could have missed it altogether, but I'm OK with that, I'll eventually read it and act upon it. My point is, the user should decide on the policy, not the tool.

[hlandau]

Here's the situation.

A strict reading of the -02 ACME draft, as I see it, specifies that the agreement URI needs to be updated when a new agreement URI is advertised. i.e. acmetool's behaviour here is correct.

However, it has transpired that Let's Encrypt plans to not require agreement URI updates, because automatic agreement to subsequent versions of the agreement (after a notice period) is part of the agreement, making it legally unnecessary. As such, acmetool could strictly forego this after initial agreement.

There's some discussion going on on the ACME WG list about ways in which the need to agree to a new agreement, or the absence of a need to do so even when a new agreement has been published, can be signalled. So I would expect this issue to be fixed long term.

For the time being, this behaviour will have to remain as it is. And an "agree to any agreement automatically" is obviously out of the question.

[hlandau]

Reappropriating this issue to track the spec issue.

[kkofler]

Why does it matter what the spec says? This is purely a client-side policy decision.

[kkofler]

The thing is, if I have auto-renewal set up, I expect it to actually do its job, and I don't care whether the server changed a comma in the license text. So in fact I'd argue that not only should there be an option to auto-approve all licenses, but it should even be the default (no matter whether it complies to the letter of the spec or not – as I wrote above, this is none of the protocol spec's business).

[hlandau]

The purpose of the TOS agreement aspect of the specification is to ascertain TOS agreement. It's not simply some magic dance done to make the protocol harder to use.

I'm not going to make a tool which falsely claims human assent to an agreement. Firstly, it sounds a lot like fraud to me. Secondly, I'd be causing acmetool deployments to defraud Let's Encrypt, or other ACME services. Thirdly, since the ToS is a condition of access to the Let's Encrypt service, using an electronic tool to claim assent to it when no assent is legally possible could easily be argued to have implications in terms of the authorization (and thus legality) of access to a computer system, insofar that in the absence of such assent, access cannot be considered authorized.

Even if people want to willingly, consensually say "I'm giving this tool a blank cheque to legally bind me on my behalf", a) it's unclear to me what the legal validity of granting power of attorney to a piece of software is and b) this is not a sane thing to do.

IIRC, you should be notified of any contract changes via e. mail if you gave one when registering. That gives you an opportunity to put the new URL in the response file.

This remains blocked on protocol clarification.

[lordfolken]

This issue caused down time for me as my certificate expired. --batch should be exactly that: batch. Considering I was planning on using acmetool at scale, i think i'm lucky that its only one unimportant service. If they want to update their TOS, fine. As long as I use acmetool I signal consent. If i don't agree with their change in their agreement, then i stop using the service.

[fxkr]

This is the main point of frustration with acmetool for me too.

Even the unofficial official tool, certbot, has an --agree-tos switch! Do you really need to be stricter than the de-facto reference implementation, written by the LE devs?

In any case, you shouldn't make the decision for the user. And besides, basically noone reads TOS anyway.

[hlandau]

@lordfolken This shouldn't happen. The correct way to setup acmetool is as a cronjob. If acmetool fails in this circumstance it exits with a nonzero exit code. If you have your cron system setup correctly, you should be e. mailed when this happens. You should rectify your cron configuration and ensure that it can send mail. This would have afforded you 30 days to rectify any failures before certificates expired.

[kkofler]

That assumes somebody reads the e-mails cron sends to the local root mailbox.

[kkofler]

Setting up the cronjob should be fire&forget. It should just do its job without asking anything.

[hlandau]

Any cronjob or other service needs an error reporting channel which is monitored. The provision of reliable services is not sensibly or actually obtained by some attempted enumeration of all possible failure modes and their prevention, because the failure modes of any system are innumerable, and many unpreventable. This is not a problem unique to acmetool, and even if ToS re-assent wasn't a thing, it wouldn't reduce the number of possible failure modes to zero.

If the local root mailbox is unmonitored, it should be reconfigured to forward elsewhere. The whole point of the error reporting mechanism of crond is so that administrators can be informed of errors. Setting up a high-stakes cronjob, expecting it to always work and configuring any errors to be redirected to an unmonitored mailbox is not a sensible or advised system management practice.

[asquelt]

it would be also recommended to monitor fragile parts of system, ie. public-facing certificates expiry. this is SA 101, ie. in nagios it can be achieved with:

 CHECK CERTIFICATE: check_http -H www.verisign.com -C 14

 When the certificate of 'www.verisign.com' is valid for more than 14 days,
 a STATE_OK is returned. When the certificate is still valid, but for less than
 14 days, a STATE_WARNING is returned. A STATE_CRITICAL will be returned when
 the certificate is expired.

[https://www.monitoring-plugins.org/doc/man/check_http.html]

i agree this is outside of scope of acmetool.

[haraldkoch]

If you run a small site that doesn't have a monitoring system there are lots of SaaS versions out there, including, for example, https://letsmonitor.org/

[CyBeRoni]

For the time being, this behaviour will have to remain as it is. And an "agree to any agreement automatically" is obviously out of the question.

Well, the current behaviour of failing when the ToS (url) changes, breaks automation entirely. The point of LE is to be automated. This is therefore completely counter-productive.

Most of us are perfectly fine with a blanket agreement setting. Something could be said for requiring the first agreement to be specified, but even that I feel could be foregone with. (Albeit not as a default setting.)

Some of us have more than one machine requiring certificates.

[ailin-nemui]

When the tos changes, you should manually express consent by adding an entry to your synchronised response file. This is not hard. It does not otherwise break automation. Cron notifies you via mail on cron job issues like this. Maybe this fact could be better documented. Thanks @hlandau for this easy to use no magic client

[lordfolken]

@hlandau while i agree with you on principle, the reality is such, that any sysadmin literally gets 1000s of cron emails a day. Errors need to be dealt with, but this isn't an error. This is a call for user interaction. If your program has a switch called --batch it shouldn't try to email me the ncurses based dialog with a tos agreement.

[hlandau]

ncurses is never used if you specify --batch. If you specify --batch and re-agreement is required acmetool exits with a nonzero status code as it cannot complete successfully.

The behaviour of acmetool is in compliance with the -02 revision of the specification, which is what Let's Encrypt currently implements:

If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URI where such terms
can be accessed in a Link header with link relation "terms-of-
service". As noted above, the client may indicate its agreement with
these terms by updating its registration to include the "agreement"
field, with the terms URI as its value. When these terms change in a
way that requires an agreement update, the server MUST use a
different URI in the Link header.

Subsequent revisions of the specification change how terms are agreed to. When Let's Encrypt implements subsequent revisions of the specification, acmetool will update accordingly and this issue is likely to become moot.

[kkofler]

The section you quoted just says that the server must send the current license URI to the client. It does not say that the client has to actually show the URI to the user and to require agreement to that URI in particular. Even the official client does not require that.

[hlandau]

This issue is not about initial prompting. It is about how a client responds when the advertised URI changes.

[rfc1036]

It was clarified in ietf-wg-acme/acme#204 that LE does not require explicitly agree to a new TOS.

Can you implement a way to automatically accept an updated TOS document? I am trying to use acmetool in a significant number of servers which do not have email capabilities, and this is really a showstopper for me.

[CyBeRoni]

Again this behaviour caused issues in many places for me, too. There really is no reason to not accept updates automatically.

[hlandau]

This should no longer be a relevant issue with ACMEv2 due to protocol changes, and as such will be fixed in v0.2.1.