Terms of service agreement

How should the agreement to the terms of service work? Using a flag like --agree-tos seems inappropriate as terms may change in the future. Passing the URL seems like a reasonable implementation, but that would break automation. How to notify server owners that the certificate can’t be renewed due to an outdated ToS agreement then?

Any suggestions?

Only way I see this working with automation intact is using the registered LE account email address for TOS change notifications and thus making email registration compulsory.

How should a simple client notify the user then? How should it send these mails?

Ah i see your point… the assumption is folks are running web servers with local mail MTA setup and running i.e. postfix, sendmail or exim.

it would be a required prerequisite for LE to have a MTA on server then

edit: oh wait got my wires crossed, no need for MTA, LE is sending emails from their servers not the end users

LE is sending expiry infos, yes. What should the client do? It could error out or could just agree to the new terms and keep running. Option 1 will likely result in expired certificates.

Maybe make TOS a publicly facing web page on letsencrypt.org domain and have the letsencrypt client just check for changes to that url link to determine if the TOS page has changed and the notify accordingly ?

But yeah I see the dilemma if the TOS changes are not what the end user likes and wants out, what does the LE client do hmmm

or just do what some servcies do, continued usage = agreement to new TOS and email notify of TOS changes

They're already exposed through the API. They change when the URL changes, that's not the issue.

Question is wheter something like [quote="eva2000, post:6, topic:4466"]
continued usage = agreement

is actually OK. @jsha or @schoen might have some input here.

1 Like

but the question is if it just runs with the agree switches you will never know when stuff changes you might not want, that’s a problem in the automation.

That’s why I expect LE to send out emails when things change. And it’s the reason why this thread exists.

1 Like

The Subscriber Agreement (which is our ToS) is currently linked from Policy and Legal Repository - Let's Encrypt.

Yes, our current Subscriber Agreement has language stating that notification of updates will be sent by email if you provide one, and continued use indicates agreement. This was a tricky decision, but we wound up deciding that requiring a manual re-agreement to terms would be too likely to break people's automated renewals, which would be bad.

In practical terms that means that, once an account key is registered and the operator has agreed to the Subscriber Agreement, you don't need to prompt them to re-agree.


thanks @jsha for confirmation :slight_smile:

This is a huge win for client usability. I've seen too many products crippled by their legal departments who ruined the user experience or the feasibility of killer features. Glad that this is not the case with Let's Encrypt. As a client developer, I can fully appreciate what this makes possible for users.

:tada: Thank you! :confetti_ball:


but stlyy why is registration without email even allowed? I mean with no updates to the tos you wont ever know that a new one appeared.

There are various reasons people might not want to provide an email, primarily pseudonymity. Since Let's Encrypt only certifies your control of a domain name, not your control of an email address, an email address is not required. However, we try very hard in the client to encourage people to provide one, and spell out the consequences: not providing an email means missing out on communications.

Do you think we need language for that in the ACME specification? Assumptions based on a single ToS for a generic protocol / client are dangerous. Since software can’t assume that, we would either need a whitelist (breaking automation for other servers not whitelisted), an explicit flag, language in the specification or an API endpoint to ask if such a phrase is present in the ToS.

I believe the ACME specification is fairly agnostic to any CA's terms of service - it simply describes a way for the CA to provide a link to them if it wants to.