No such challenge

[twrriegel]

I have a single domain that is refusing to reissue. I am getting a “No such challenge” error.

I have tried it with a new keyset for the domain and also a new registration but I am getting the same response.

I have included the relevant challenge from the new authz request. I am using ACME version 1. I have also included the URL to the challenge being requested.

How can I troubleshoot this? This is the only domain giving me trouble all the others are working perfectly.

—new authz json snip—
{
“type”: “http-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/zKfXEs2o4OTK3vMo6S751sXFFfFPT6iFu4mACSAGyvI/8573482481”,
“token”: “OvWsP2_ZAc-rpqmOr7tqueFLUOzR7IkBXWzIALt-5Oc”
}
—new authz json snip—

—challenge—
http://countywidenews.com/.well-known/acme-challenge/OvWsP2_ZAc-rpqmOr7tqueFLUOzR7IkBXWzIALt-5Oc
—/challenge—

—request—
https://acme-v01.api.letsencrypt.org/acme/challenge/zKfXEs2o4OTK3vMo6S751sXFFfFPT6iFu4mACSAGyvI/8573482481
—/request—

—response—
{
“type”: “urn:acme:error:malformed”,
“detail”: “No such challenge”,
“status”: 404
}
—/response—

[Osiris]

What client are you using? Could you please provide the full command line you’ve used? And paste all the client output, not just the ACME stuff?

[twrriegel]

I am using curl and a client I wrote to make the requests. Here is the full log of each http request and response…

https://2.lionslight.com/api/keymanager/viewlog/cron_1549307829042.log

For reference here is a log that contains a cert successfuly issued.
https://2.lionslight.com/api/keymanager/viewlog/cron_20181224031244_9132.log

You can click on each request to see everything sent to and recieved from the server.

[rg305]

The one that fails shows content type image.

[twrriegel]

Thats a red Herring.

I fixed the content type and re ran it. Here is the latest log…

https://2.lionslight.com/api/keymanager/viewlog/cron_1549318635883.log

[jsha]

According to your log, your new-authz request is from October 2018. The resulting authz has long since expired (as indicated by the “expires” field in the response JSON). You should be checking expiration times and creating new authorizations if necessary.

Also note: If you’re developing a new client in 2019, you should be developing against the ACMEv2 API, not the ACMEv1 one.

[rg305]

@twrriegel

Thats a red Herring.

OK.

How about line #1 ?:
_request:url https://acme-staging.api.letsencrypt.org/directory_

[which doesn't match the production lines that follow nor does that line show on the one that works]

[twrriegel]

Bingo!

https://2.lionslight.com/api/keymanager/viewlog/cron_1549329620962.log

Thanks for taking a look at this for me. The problem was the expired authorization. When I originally wrote my client I always got a new authorization and my last round of edits I started caching the answer but missed the expiration. Thanks again. I updated my code to go out for a fresh authorization if the last one has expired. I also added a “unbase64” payload in the log, makes it easier to see the actual payload.

Turns out the staging url was there as a vestige from my fiddling around. It has been corrected also.

Thanks for the heads up on ACME V2, I am actually in the process of finishing up my ACME V2 client, its about 95% ready. I just need to do some housekeeping to integrate it with my V1 client.