Skip to content
This repository has been archived by the owner on Dec 1, 2018. It is now read-only.

Action required: Let's Encrypt subscriber agreement URL Change #46

Open
cpu opened this issue Nov 13, 2017 · 0 comments
Open

Action required: Let's Encrypt subscriber agreement URL Change #46

cpu opened this issue Nov 13, 2017 · 0 comments

Comments

@cpu
Copy link

cpu commented Nov 13, 2017

Hi there,

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

https://github.com/kristapsdz/acme-client-portable/blob/e82c130dd942a74c50c1631042c1bc60fafe8bad/main.c#L35:L36

This URL is going to change November 15th. If your project does not address the stale URL at this point 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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant