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


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 ( / - 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.


[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:
[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’ => ‘’,
‘kid’ => ‘’,
[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”: “”,
“token”: “noQ96FNT8eu5dhI9Yfa2JLN9QTAkaWnbuL73m3aUBVQ”

1 Like

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



Authorizations can be cached for up to 30 days.

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


Hi @thomas3,

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

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!


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.


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.


Glad to hear it! :tada:


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