Static terms of service

I posted about this a while ago, and as I’m looking at ACME v2 it still strikes me as a real liability that LE wants no static URL that will return the terms of service.

Currently the v01 service will redirect a browser from to the up-to-date URL. This is extremely useful because it gives clients a URL that we can hard-code in our applications. It makes for one less trip to the server.

We used to do our v1 support by loading the /directory endpoint as envisioned, but then we had clients who, for one reason or another, stalled at the point of loading that endpoint. Switching to the static URL was a big improvement on our end.

Could this not be retained via a "meta": { "static-terms-of-service": "…" URL? Or could LE, at least, retain it on the v02 service?

Hi @FGasper, thanks for the question,

The /directory endpoint needs to be GETed initially one way or the other to start the issuance process - what round trip does it save vs retrieving the meta URL alongside the other endpoints with the initial /dir fetch? Am I misunderstanding?

How does your ACME client learn the endpoint URLs it needs to actually continue the ACME issuance flow if the /directory endpoint can’t be loaded/reached?

If the directory URL is unreachable/stalling we would be happy to investigate the root cause of that problem.

I’m not sure I understand this feedback. Why is it disadvantageous to have the exact URL in the meta directory instead of a URL that redirects to the current URL? Especially given your feedback above that accessing the directory endpoint can stall for some users. Putting a different URL here would still have the same disadvantages no?

We don’t start the issuance flow until the user accepts the terms of service.

The /directory endpoint needs to be GETed initially one way or the other to start the issuance process
This is true; however, for the mere presentation of a URL that will return the terms of service, there’s a round-trip needed to get /directory, whereas /terms, since it returns a Location header, automatically redirects the browser.

In other words, we can tell an end user “Click here to see the terms of service” without having to fetch the URL from LE because the static URL will redirect the browser. Without that static URL, we depend on the user’s connection to LE in order to show the UI, which has been problematic.

My thought about the static-terms-of-service in the directory is that it would be cached. But it may be better just documented separately?

Our hope is that you actually don’t hard-code this Let’s Encrypt URL in your clients, but get it from the directory. This will increase the chance that your client will be ACME-compatible rather than just Let’s Encrypt-compatible. :slight_smile:

1 Like

I get that. :slight_smile: We also worry, though, about the end-user experience and reliability of the application. Generic ACME compatibility is nice, but it’s far less of concern to customers.

The “pre-round-trip” to LE solely to show a ToS URL degrades the user experience (particularly for clients outside North America) and has occasionally led to nonfunctional UIs when, for whatever reason, a client wasn’t able to reach LE. It requires an extra user interaction if we have to download the ToS URI separately from the UI.

Also, we’re already hard-coding /directory independently of the spec, right? So there will always be some degree of specificity in a given CA’s setup.

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