Authorization deactivation

[roland]

Boulder recently added support for deactivating existing valid or pending authorizations and Let’s Encrypt has enabled this feature on both the staging and production endpoints.

This allows you to deactivate a authorization that has just been created or already exists and has been validated. Deactivating an authorization prevents it’s further use for any validation or issuance.

In order to deactivate an authorization a signed message with the content {"resource": "authz", "status":"deactivated"} needs to be POST’d to the URI of the authorization (i.e. .../acme/authz/id). Currently there are no clients that support this feature but a few are working on it.

Happy to answer any questions people have!

[serverco]

HI @roland, thanks for this. Can you provide a little more detail though please, as it doesn't seem to be working for me

If I have a challenge location

https://acme-staging.api.letsencrypt.org/acme/challenge/xxx/yyy

and I POST to that URI (correctly signed) the payload

{"status": "deactivated"}

then I get a response "Request payload does not specify a resource"

if I use

"{"resource": "challenge", "status": "deactivated"}"

then I get a 202 response and that the ... "status": "valid" ... and any other challenge type (such as "authz" ) tells me that the challenge type is incorrect.

I assume I'm missing the obvious somewhere ...

[serverco]

OK, I think I worked it out ...

The request needs to be sent to the relevant auth location

https://acme-staging.api.letsencrypt.org/acme/authz/asdfg

and the payload needs to be

{"resource": "authz", "status": "deactivated"}

Working perfectly in all my tests so the GetSSL client now supports this

[roland]

Hey! Glad you figured it out, I’ll update my original post to be a little more descriptive, I realize now I totally forgot to include the resource in my original example.