Action required: Let's Encrypt subscriber agreement URL Change

[cpu]

Hi there,

Your project has a hardcoded URL reference to the current Let's Encrypt subscriber agreement:

https://github.com/Neilpang/acme.sh/blob/cc3660e25964513a618e5da4a4a795e638549bbc/acme.sh#L18

This URL is going to change November 15th. If your project does not address the stale URL subsequent new-registration/account requests may begin to fail.

ACME clients do not need to hardcode a subscriber agreement URL and Let's Encrypt discourages this practice. You should learn the current agreement URL at runtime instead so that it is always current.

One option is to reference the agreement URL from the "meta" key's "terms-of-service" element from the response to a GET request to the ACME server's /directory endpoint:

{
  <snip>
  "meta": {
        "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"
  },
  <snip>
}

A second option is to learn the current subscriber agreement URL at runtime as part of the new-reg flow: Client code can submit an initial new-reg request without an agreement value in the request payload. The account will be created and in the response will be a Link header with a terms-of-service relation pointing at the current agreement URL. Once this Link header has been seen the client should update the registration to agree to the terms by sending a payload with the agreement value set to the current agreement URL.

Thanks!

[Neilpang]

Thanks for your info.
acme.sh is able to read the tos url from the meta node, based on ACME protocol.
https://github.com/Neilpang/acme.sh/blob/cc3660e25964513a618e5da4a4a795e638549bbc/acme.sh#L3117

But let's see what will happen then. I will keep an eye on it.

Thanks.

[cpu]

Hi @Neilpang - Thanks for that note. As you can probably guess I did only a surface level search across Github for the existing URL and missed that acme.sh is also able to look at the meta node.

Is the DEFAULT_AGREEMENT being kept in case the meta node isn't present? It is probably safe to assume we won't remove it :-)

[Neilpang]

@cpu
Yes, correct. DEFAULT_AGREEMENT is just a default value if to the tos is missing in the meta node.
As ACME protocol requires: acme.sh tries to register account with empty tos url first, if the CA server gives back a tos url in the response, acme.sh will retry again with the given tos url.
If the CA server doesn't give back any tos url, acme.sh uses the default one.

[cpu]

Hi again @Neilpang,

As ACME protocol requires: acme.sh tries to register account with empty tos url first, if the CA server gives back a tos url in the response, acme.sh will retry again with the given tos url.

Perfect 👌

If the CA server doesn't give back any tos url, acme.sh uses the default one.

Since the default value is Let's Encrypt specific, and we're committed to always giving back a ToS URL, it should be safe to remove this instead of having to update it whenever we change the URL. If you see a case where there is no meta directory element and no ToS is returned from the new-reg without an agreement it's definitely a Boulder bug!

I'll close this issue since it sounds like you have everything required in place ahead of the 15th.

Thanks for looking at this Neil, I appreciate it!

[Neilpang]

it should be safe to remove this instead of having to update it whenever we change the URL.

good, let me think about it .