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