Challenge is always pending, no incoming requests from Let's Encrypt

Hello.

I have the custom Let’s Encrypt client embedded in my infrastructure.
Recently due to the move to POST-as-GET I have updated all calls to Let’s Encrypt API and know for sure that now Order requests and Certificate download request are OK in Staging env, except the http-01 challenge result check.

In my nginx log i see few rows with Let’s Encrypt requesting the challenge file with 200 status (3 queries from 82.165.70.112), but not for all requested challenges into the queue.

my queue consists of several domains related to this website (on same IP):
maks-it.com
www.maks-it.com
it.maks-it.com
www.maks-it.com
ru.maks-it.com
www.ru.maks-it.com
api.maks-it.com
www.api.maks-it.com

During the polling with POST-as-GET request, all challenges remain in pending state, probably also because not all requests from Let’s Encrypt I’m receiving, that’s strange cause http with ./well-known Get requests i’m redirecting directly to server folder holding files. I have tested every domain from another machine outside, so at least i should see Let’s Encrypt requests in my nginx access log…

Changing requesting order account had no effects.

Kind regards

1 Like

Hi @maks-it

if there is

no incoming requests from Let’s Encrypt

your required command doesn't work.

You have to send a POST command to the challenge url to say:

Please, check that challenge: http or dns or alpn.

Then Letsencrypt checks that challenge and answers with a new status valid / invalid.

And you have to check the complete order if the order is ready. If yes, you can use the finalize url to upload your CSR.

1 Like

Thank you for your fast reply!

here is my order request example, that worked few months ago, and I haven't touched this part.

"protected": {
"alg":"RS256",
"jwk":null,
"kid":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/11908841",
"nonce":"0002drZLgOjPWHJz1geOmWDkT1ff4OPUkhnCGZiH9cGo46A",
"url":"https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
"Host":null
},

"payload: {
"Location":null,"status":null,"expires":null,
"identifiers":[
{"type":"dns","value":"maks-it.com"},
{"type":"dns","value":"www.maks-it.com"},
{"type":"dns","value":"it.maks-it.com"},
{"type":"dns","value":"www.it.maks-it.com"},
{"type":"dns","value":"ru.maks-it.com"},
{"type":"dns","value":"www.ru.maks-it.com"},
{"type":"dns","value":"api.maks-it.com"},
{"type":"dns","value":"www.api.maks-it.com"}
],
"notBefore":null,
"notAfter":null,
"error":null,
"authorizations":null,
"finalize":null,
"certificate":null
},
"signature": "...."

Then I have implemented POST-as-GET for challange request and polling:

"protected": {
"alg":"RS256",
"jwk":null,
"kid":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/11908841",
"nonce":"0001EkwwvLPMoXogD0gbEgYNftmoJ-G1c40G733h2-i7bo4",
"url":"https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/29225161",
"Host":null
},
"payload": "",
"signature": "..."

When you spoke about:

I didn't understood immediately that you're referring to this documentation part
https://tools.ietf.org/html/rfc8555#section-7.5.1

7.5.1. Responding to Challenges
To prove control of the identifier and receive authorization, the
client needs to provision the required challenge response based on
the challenge type and indicate to the server that it is ready for
the challenge validation to be attempted.
The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).

And yes... this is not a normal POST-as-GET that I had to implement, but, as documentation explains, I had to put empty json body, by converting to base64 {} without quot.

So my request had to be:
"protected": {
"alg":"RS256",
"jwk":null,
"kid":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/11908841",
"nonce":"0001EkwwvLPMoXogD0gbEgYNftmoJ-G1c40G733h2-i7bo4",
"url":"https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/29225161",
"Host":null
},
"payload": Base64({}),
"signature": "..."

Now client works again!

Regards.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.