Originally created by @rolandshoemaker on GitHub (Aug 1, 2016).
Boulder provides the current subscriber Agreement in a Link header of the type terms-of-service in response to a valid /acme/new-reg POST request, this should be used instead of hard coding the most recent URL.
Continuing to hard code the URL will cause consistent failures for anyone trying to create a new registration whenever Let's Encrypt chooses to update their agreement.
Originally created by @rolandshoemaker on GitHub (Aug 1, 2016).
Boulder provides the current subscriber Agreement in a `Link` header of the type `terms-of-service` in response to a valid `/acme/new-reg` POST request, this should be used instead of hard coding the most recent URL.
Continuing to hard code the URL will cause consistent failures for anyone trying to create a new registration whenever Let's Encrypt chooses to update their agreement.
AFAIK, the reason for the current “hard-coding” (it's not hard-coded, it's a variable adjustable in the config file) is that that in theory provides a fool-proof method of demonstrating you agree with the current terms of service.
I don't think it should be automatically drawn from the headers — but perhaps it would be smart for letsencrypt.sh to include logic that informs you “The terms of service have updated; here is the link to the Subscriber Agreement. Please update your configuration to agree with the new terms.”
@Celti commented on GitHub (Aug 1, 2016):
AFAIK, the reason for the current “hard-coding” (it's not hard-coded, it's a variable adjustable in the config file) is that that in theory provides a fool-proof method of demonstrating you agree with the current terms of service.
I don't think it should be automatically drawn from the headers — but perhaps it would be smart for letsencrypt.sh to include logic that informs you “The terms of service have updated; here is the link to the Subscriber Agreement. Please update your configuration to agree with the new terms.”
Just added support for this in vestacp.
You can use the following command to get the agreement url agreement=$(curl -s -I "$api/terms" |grep Location |cut -f 2 -d \ |tr -d '\r\n') with $api being api='https://acme-v01.api.letsencrypt.org'
@pcfreak30 commented on GitHub (Aug 3, 2016):
Just added support for this in vestacp.
You can use the following command to get the agreement url `agreement=$(curl -s -I "$api/terms" |grep Location |cut -f 2 -d \ |tr -d '\r\n')` with `$api` being `api='https://acme-v01.api.letsencrypt.org'`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rolandshoemaker on GitHub (Aug 1, 2016).
Boulder provides the current subscriber Agreement in a
Linkheader of the typeterms-of-servicein response to a valid/acme/new-regPOST request, this should be used instead of hard coding the most recent URL.Continuing to hard code the URL will cause consistent failures for anyone trying to create a new registration whenever Let's Encrypt chooses to update their agreement.
@Celti commented on GitHub (Aug 1, 2016):
AFAIK, the reason for the current “hard-coding” (it's not hard-coded, it's a variable adjustable in the config file) is that that in theory provides a fool-proof method of demonstrating you agree with the current terms of service.
I don't think it should be automatically drawn from the headers — but perhaps it would be smart for letsencrypt.sh to include logic that informs you “The terms of service have updated; here is the link to the Subscriber Agreement. Please update your configuration to agree with the new terms.”
@pcfreak30 commented on GitHub (Aug 3, 2016):
Just added support for this in vestacp.
You can use the following command to get the agreement url
agreement=$(curl -s -I "$api/terms" |grep Location |cut -f 2 -d \ |tr -d '\r\n')with$apibeingapi='https://acme-v01.api.letsencrypt.org'@lukas2511 commented on GitHub (Jan 29, 2017):
Closing in favor of #346, thanks for your hints.