Determine if Terms and Conditions have changed w/o a sign failure

Issuance Tech
1

Is there a way to determine if the Ts&Cs have changed apart from just having Certbot return an error?

We plan to have our users explicitly accept the LetsEncrypt Ts&Cs once when they start using our auto signing feature (we add the --agree-tos to the Certbot command line when they do)

They will not need to re-accept them again until they have changed, possibly years later.

Is there a way for us to determine that the Ts&Cs have changed apart from running Certbot without the --agree-tos and having it fail?

And if there isn’t, are the errors produced when Certbot finally fails years later (due to a missing --agree-tos) programatically parsable, so we can display a sensible error to the user?

Thanks

2

Hi @chmckenn

every acme-server has a directory:

Letsencrypt version 2:

https://acme-v02.api.letsencrypt.org/directory

There you can find a link to the TOS:

Save this url and check sometimes, if this url has changed.

1 Like
3

But see also:

2 Likes
4

Is the acceptance of the T&Cs stored on the LetsEncrypt servers of just locally in the certbot directories?

If I call certbot with --agree-tos the first time, and I then subsequently call certbot without the --agree-tos flag, will this keep working until the T&Cs change?

And finally, is there a way to simulate the T&Cs changing using the boulder docker image?

Thanks very much

5

It’s stored in Boulder against the ACME registration, and also in Cerbot’s regr.json.

Yes, --agree-tos only has an effect during ACME account registration, which only happens once with Certbot, unless you nuke the previous registration somehow.

(A guess): From what I can tell, Boulder doesn’t yet implement that part of the spec: https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.3.4

Edit: if you mean to change the ToS for new registrations, you can change it in config/wfe2.json and wfe.json (for ACME v2 and ACME v1, respectively).

6

So I have accepted the current ToS and all future ones too??

If the ToS change, will my signing request fail or prompt me to re-accept the new ToS?

7

Well, that's what 7.3.4 in the spec is about. The ACME server might or might not be willing to accept new orders without making the client agree to the new agreement.

In reality, neither Certbot nor Boulder implement this behavior, so even if new T&Cs come out, your signing requests will not require accepting the new agreement.

I'm not sure what the plan for the future is. You could tack on --agree-tos to all of your commands in anticipation of future changes in behavior, but it doesn't make any sense today.

--

I remember during last year's agreement updates, acmetool was one of the clients that refused to renew certificates because of the agreement change. However, there is this statement to consider:

8

Boulder's ACME v2 API does implement the boolean termsOfServiceAgreed field as described here. The V1 API continues to use the legacy method of requiring the URL of the TOS being agreed to be sent to the server.

9

Sorry, I was more referring to the userActionRequired behavior.

10

Oops! My mistake :slight_smile: You're correct we don't implement that behaviour. Sorry @_az!

11

So we can’t simulate the ToS changing? Well, I suppose if this has no effect on Certbot after registration, then it doesn’t matter.

Is there a chance of this behaviour changing in V1? Our release cycles are quite long, so we will be using V1 for a few years at least. If the LetEncrypt server changes it mind and decides it requires re-acceptance of the ToS once they have changed, we are in trouble.

I think our legal team is worried that the ToS could theoretically be changed to include e.g. a statement that declares that usage of this service entitles LetsEncrypt to 10% of your global revenue.
Hence accepting the current ToS and all future versions makes them nervous.

12

We won’t make this change.

Section 5.6 of the agreement outlines how we would notify you of changes. It wouldn’t be a silent change that you have no chance to vet:

ISRG may modify this Agreement from time to time. Each modified version of this Agreement will be
posted to ISRG’s Let’s Encrypt website (letsencrypt.org) at least fourteen (14) days before it becomes
effective. If such new version contains material changes and You have provided ISRG with an email
address, ISRG will send an email to such address notifying You of such new version at least fourteen (14)
days before it becomes effective. In addition, major changes will be flagged with a new Subscriber
Agreement version number in the ACME protocol, so You may be able to configure Your ACME Client
Software to notify You of such changes.

1 Like
13

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