Incorrect TXT record from AcmeClient.php

[nsmartrevitalised]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: revitalised-staging.co.uk

I ran this command: using acmephp client (https://github.com/acmephp/core)

It produced this output:
In AcmeClient.php line 209:

Challenge failed (response: {“type”:“dns-01”,“status”:“invalid”,“error”:{“type”:“urn:ietf:params:acme:error:unauthorized”,“detail”:“Incorrect TXT record “qqt7KydNxjV1KaWKY2suns_Z2CTCXNsI8_BSWdBfljA.TcmcbxQta9-p76HU9fFgNetOS_D67Qy9llYI4gDLmpg” (and 1 more) found at _a
cme-challenge.revitalised-staging.co.uk”,“status”:403},“url”:“https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/41061749/3JSD-Q",“token”:"qqt7KydNxjV1KaWKY2suns_Z2CTCXNsI8_BSWdBfljA”}).

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is: cloudflare

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

Attempting to just test the validation for our deployment, using the standard repo but eh validation always fails, TXT record is almost always found (usually very quickly too) but it seems the acmephp client is generating the wrong DNS payload. I have tried this with HTTP validation and it works fine using the payload there but not for DNS. Been trying to find the issue for a few days and really hitting the wall of what could be the problem now
Thanks in advance

[mnordhoff]

HTTP-01 validation and DNS-01 validation don't use precisely the same payload: DNS-01 validation uses a base64-encoded hash of what HTTP-01 uses directly.

For HTTP-01:

A client fulfills this challenge by constructing a key authorization
from the "token" value provided in the challenge and the client's
account key. The client then provisions the key authorization as a
resource on the HTTP server for the domain in question.

For DNS-01:

A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key. The client then computes the SHA-256 digest [FIPS180-4] of the key authorization.

The record provisioned to the DNS contains the base64url encoding of this digest. The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.

RFC 8555: Automatic Certificate Management Environment (ACME)

[nsmartrevitalised]

@mnordhoff thanks, i think ive read so much of this I missed the sha256 and thought it was already being done by the client. I shall retry and hopefully that works

[nsmartrevitalised]

Managed to resolve this, using the corePHP library i saw the JWK thumbprint was being encoded and thought that step was already complete.
I had to do the following steps to resolve (had to implement something ourselves due to some constraints;
$encoder = new Base64SafeEncoder();
$encoder->encode(hash(“sha256”, $authorizationChallenge->getPayload(), true));
rather than just the payload