During a final round of review within the IETF before the creation of RFC 8555 the draft ACME protocol was updated to replace unauthenticated GET requests to resources (certificates, orders, authorizations and challenges) with an authenticated POST carrying a special empty JWS body (called a “POST-as-GET” request by RFC 8555).
We have added support for the POST-as-GET construction for certificates, orders, authorizations and challenges to the ACME v2 API while simultaneously allowing legacy GET requests to these resources. Clients may begin sending POST-as-GET requests to the staging and production V2 API as of October 25th, 2018.
On November 1st, 2019December 4th, 2019 we will remove support for unauthenticated GETs from the staging V2 API, requiring client support for POST-as-GET.
On November 1st, 2020 we will remove support for unauthenticated GETs from the production V2 API.
ACME v2 Clients that do not have support for POST-as-GET will not be able to issue or renew certificates in the staging and production environments after the above deprecation dates.
In addition to the V2 staging API ACME client developers are encouraged to use the Pebble test server version 2.x.x or later to test client POST-as-GET support. Please see the “GET and POST-as-GET Requests” section of RFC 8555 for more information.
After evaluating the current level of POST-as-GET support across requests to the ACME v2 API we have decided to push back our original deprecation schedule.
Previously we announced deprecating unauthenticated GET requests for the prod V2 API on November 1st, 2019. Our current plan is to use this date as the staging environment deprecation date and to remove production support one year later, on November 1st, 2020.
I have updated the original post to reflect these new dates (and to reference RFC 8555).
Unfortunately we've missed this November 1st date for roll-out of mandatory POST-as-GET in the staging environment. In the future I'll make sure there are multiple people tracking upcoming announced API changes so that my own lapse in memory won't cause unexpected delays. Sorry about any inconvenience!
We're now planning to make this change active in the staging environment on Wednesday December 4th, 2019.
After Dec 4th unauthenticated HTTP GET requests to ACME v2 resource URLs will return HTTP status code of 405 "method not allowed" and a body containing a JSON problem with type "urn:ietf:params:acme:error:malformed". POST-as-GET requests authenticated by a signature from an account other than the creating account will return an HTTP status code of 403 "forbidden" and a body containing a JSON problem with type "urn:ietf:params:acme:error:unauthorized".
If you are a Certbot user and want to ensure you will not be affected by this change make sure sudo certbot renew --dry-run succeeds after Dec 4th. If it does not, follow the instructions at https://certbot.eff.org and update to the most recent version of Certbot offered for your OS.
Previously, we announced the deprecation of unauthenticated GET requests for the Production ACMEv2 API will occur on November 1st, 2020. After evaluating the current level of POST-as-GET support across requests to the ACMEv2 API we have decided to indefinitely postpone our deprecation plan.
We believe that all ACME clients should implement POST-as-GET for client compliance with RFC 8555. Our Staging environment will continue enforcing mandatory POST-as-GET and clients can use it for testing. In the future, we hope to see all clients compliant with the spec so we can remove support for unauthenticated GETs from the Production API. For the time being, we have removed the event from our ACME API Events calendar and thank all the ACME client implementers who have enabled POST-as-GET.