I have a few pending authz urls I would like to do this:
LE_KEY=XXXX clearpendingauth https://acme-v01.api.letsencrypt.org/acme/challenge/XXXX
Does such a clearpendingauth tool exist? I couldn’t see an option in certbot 0.14.1.
If not I will write it and open source it but if possible I’d prefer to use a standard and not create fragmentation of the tool ecosystem.
Okay sounds like a fun weekend project then, I’ll post a link when I have it.
I’m not aware of a stand-alone tool but the Go ACME client “Lego” has a disableAuthz function it uses internally for this purpose that might be a useful reference:
(EDIT: the reason this fails is not disableAuthz, it’s that I was passing the challenge URL not the authz URL - read further comments for details)
The disableAuthz function in lego seems to fail with:
JWS resource payload does not match the HTTP resource: authz != challenge
The function is sending this signed json: {"resource":"authz","status":"deactivated"}
To an endpoint: https://acme-v01.api.letsencrypt.org/acme/challenge/XXXX where XXXX is someb64urlcode/someid
I tried pulling out the code and cleaning it up if you want to have a look:
(This currently doesn’t work because of the aforementioned error)
To be explicit I haven’t tried using Lego for this, I just knew it existed. Totally possible it’s buggy!
This is a URL for the challenge endpoint - you need to be posting to the authz endpoint. An authorization is a higher level object that contains references to individual challenges. I’d expect the URL you provide to be of the form:
https://acme-v01.api.letsencrypt.org/acme/authz/$IDENTIFIER_HERE
This error is because the signed JWS body’s resource value (authz) does not match the endpoint you’re POSTing. This check is done because otherwise ACME would be open to subtle attacks that may take a signed JWS body from one request to use it against a different endpoint.
Thanks cpu!
It looks like I’m logging the wrong URLs then because I only have challenge URLs in my logs!
Outstanding. I guess I’ll try to figure out what the authz URLs are and whether I can log them instead.
One potential workaround I just remembered: If you send a GET request to a challenge URL you should get back a JSON response body with an additional Link HTTP response header with the rel=up pointing at the Authz, like so:
Link: https://acme-v01.api.letsencrypt.org/acme/authz/$IDENTIFIER_HERE;rel=“up”
That should be sufficient to find the authz URL for the challenge URL’s you have logged with a bit of extra work.
I think this “Up” relation might be removed in the latest versions of the draft ACME specification but it will continue to work with the existing Boulder implementation for the time being.
Awesome! It looks like it worked
$ acmecancel "https://acme-v01.api.letsencrypt.org/acme/authz/XXX"
$ acmecancel "https://acme-v01.api.letsencrypt.org/acme/authz/XXX"
acmecancel: could not disable authz: Error deactivating authorization :: only valid and pending authorizations can be deactivated
So it looks like it’s not pending anymore, but the corresponding challenge still says its pending.
$ curl https://acme-v01.api.letsencrypt.org/acme/challenge/XXX/id
{
"type": "http-01",
"status": "pending",
"uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/XXX/id",
"token": "XXX"
}
But I guess there’s not a pending challenge rate limit only the pending authz limit, right?
Also it totally looks like the XXX from https://acme-v01.api.letsencrypt.org/acme/challenge/XXX/id is the same as the XXX from https://acme-v01.api.letsencrypt.org/acme/authz/XXX
So if that’s true in general that makes it easier.
That’s correct. An authorization has one or more challenges (For LE right now it’s three challenges per authz: DNS-01, TLS-SNI-01 and HTTP-01). If your client solves one challenge (say HTTP-01), then that specific HTTP-01 challenge will be set to VALID while the DNS-01 and TLS-SNI-01 challenges will remain PENDING since they are unsolved. The authz will be set to VALID as soon as one challenge is VALID.
In general clients should concern themselves with authz state as opposed to individual challenge state since authz’s can be reused in some conditions and clients can be confused when they request a new authz to do say, a DNS-01 challenge, but get back an already valid authz that was validated by HTTP-01 at a prior date and has a PENDING DNS-01 challenge.
I think this is an implementation decision of Let’s Encrypt/Boulder and not mandated by the ACME protocol. You might run into trouble in the future if you rely on this and the tool is used against a different CA implementing ACME.
The tool now expects an authz URL. It’s the user’s responsibility to do any transformation or lookup to get the authz URL. I’m also the only user right now so I think it will be fine.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.