Custom V1 -> V2 Client Upgrade - LE Stage not reaching out via HTTP to verify?

[thomas3]

Hi,

I have a custom v1 client that I wrote over 2 years ago, it’s currently
handling the provisioning and renewal of over 500 certs without any issues.

I recently received a notification email from LE - indicating I should upgrade it to use v2.
So thanks for the heads up and that’s what I’m attempting to do currently.

Unfortunately a number of the other PHP libraries referenced on the website do
not work anymore due to recent changes which disallow simple unauthenticated GET requests for some endpoints - they now required POST-as-GET.

So far I’m able to:

• request directory information
• request my account info using the key: Payload: {“onlyReturnExisting”:true} - and the account URL (kid) / “status”: “valid”
• create a new order for 2 domains (floodscatter.com / www.floodscatter.com) - simply a test domain I’m using - and ignore the fact it’s already running SSL - that cert was requested via the V1 client
• retrieve the 2 authorizations
• fetch the challenges from those authorizations.

Where I cannot get any further is when I send an empty payload to both of the challenge URL’s for the HTTP type, the LE stage system never reaches out to that domain and attempts to verify: /.well-known/acme-challenge/XYZ. I know on the server which is currently responding for the domain - those challenge files are not there yet - but I should at least see a request from LE - and the server returning a 404?

An I missing something or making a mistake somewhere?
Below is the last request to the challenge URL that doesn’t seem to trigger a verification request to my domain.

Any advice would be appreciated.

Thanks.

---

[2020-01-20 14:25:18] - [dev] - Updated nonce: 0001tvxBzNXhl_oXNB2lwp48QOYOE5rIf2lJO49h8068fSQ
[2020-01-20 14:25:18] - [dev] - Challenge is still not verified - waiting
[2020-01-20 14:25:28] - [dev] - Target URI: https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/33922965/CF9k4g
[2020-01-20 14:25:28] - [dev] - Payload:
[2020-01-20 14:25:28] - [dev] - header data
[2020-01-20 14:25:28] - [dev] - array (
‘nonce’ => ‘0001tvxBzNXhl_oXNB2lwp48QOYOE5rIf2lJO49h8068fSQ’,
‘alg’ => ‘RS256’,
‘url’ => ‘https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/33922965/CF9k4g’,
‘kid’ => ‘https://acme-staging-v02.api.letsencrypt.org/acme/acct/2801338’,
)
[2020-01-20 14:25:28] - [dev] - Response code: 200
[2020-01-20 14:25:28] - [dev] - Response body
[2020-01-20 14:25:28] - [dev] - {
“type”: “http-01”,
“status”: “pending”,
“url”: “https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/33922965/CF9k4g”,
“token”: “noQ96FNT8eu5dhI9Yfa2JLN9QTAkaWnbuL73m3aUBVQ”
}

[bruncsak]

You should extract from the reply json object the “url”, and send a post with “{}” payload to trigger the identifier challenge verification. Check RFC8555.

[rg305]

@thomas3

Am I missing something or making a mistake somewhere?

Maybe...

@thomas3

but I should at least see a request from LE - and the server returning a 404?

Authorizations can be cached for up to 30 days.

@thomas3

Any advice would be appreciated.

Try changing the FQDN requested to something new/unused.
[that may force revalidation]

[cpu]

Hi @thomas3,

Welcome to the community forum I've moved your post to the Client Dev section where I think it will be a better fit.

@thomas3

Where I cannot get any further is when I send an empty payload to both of the challenge URL’s for the HTTP type, the LE stage system never reaches out to that domain and attempts to verify: /.well-known/acme-challenge/XYZ. I know on the server which is currently responding for the domain - those challenge files are not there yet - but I should at least see a request from LE - and the server returning a 404?

I took a peek at the staging environment logs and I can confirm what @bruncsak (thanks!) is saying in their reply: Your client appears to be making POST-as-GET requests to the challenges (JWS payload == ""), but not any challenge initiation POSTs (JWS payload == "{}", the trivial JSON object).

The difference is subtle (and stems from some awkward API design) but is important in this context. The {} is how the ACME server knows you want to initiate the challenge, not fetch its details.

Hope that helps!

[cpu]

@thomas3

Unfortunately a number of the other PHP libraries referenced on the website do
not work anymore due to recent changes which disallow simple unauthenticated GET requests for some endpoints - they now required POST-as-GET.

I'm not sure about the other PHP clients but I know for sure ACMEPHP works with POST-as-GET (ref #178). They test against Pebble and it has been enforcing mandatory POST-as-GET for some time now.

[thomas3]

Hi - Thanks everyone for your prompt response on where I had made a mistake!
I’m now able to trigger the verification.

Have a great day.

[cpu]

@thomas3

I’m now able to trigger the verification.

Have a great day.

Glad to hear it!