Invalid DNS record

Client dev
1

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. crt.sh | 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: auth.runningplanandtrack.com

I ran this command: self-made ACME API following RFC-8555

It produced this output:

{
  "identifier": {
    "type": "dns",
    "value": "auth.runningplanandtrack.com"
  },
  "status": "invalid",
  "expires": "2022-04-20T15:52:58Z",
  "challenges": [
    {
      "type": "dns-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:unauthorized",
        "detail": "Incorrect TXT record \\"fybx82wB0taTO6PDmjyqTSdsNIABEEfqFLDSyfByYg0\\" found at _acme-challenge.auth.runningplanandtrack.com",
        "status": 403
      },
      "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/2176560528/TK8rAA",
      "token": "fybx82wB0taTO6PDmjyqTSdsNIABEEfqFLDSyfByYg0",
      "validated": "2022-04-13T15:54:00Z"
    }
  ]
}

My web server is (include version): self-made web server

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

My hosting provider, if applicable, is:

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

I have created the DNS record and it is found as the message says, but it still says that it is invalid. I have checked all DNS records and everything seems fine. Can somebody help me with this issue? I have checked the issues with the same error, but none of them had a solution that worked for me.

1 Like
2

Wait a few hours and then try again.

Or use the production environment directly.

3

Waiting doesn't really resolve an incorrect TXT record :wink:

@franciscofabian Did your client include the " around the token value?

1 Like
4

Yeah, I tried waiting for several hours but no luck, also with the production environment.

@Osiris I do include the " around the token value

2 Likes
5

You should not include the ".

3 Likes
6

I include it because my DNS provider (Amazon Route 53) does not allow TXT records without quotes, which follows RFC-1464. So I cannot not include the "

1 Like
7

I don't see anything wrong with the format of the TXT record. It looks the same as my Route53 value (with quotes in response to dig).

Did you know the challenge value changes each time? Could you just have had a stale value in the TXT record?

3 Likes
8

Yes, I do change the values every time. Everything seems also fine for me. I have tried everything that I could think of for several days but I still always always this error. In the response the token found in the TXT record is the same as the token attribute, so I don't know why it gives an error

2 Likes
9

If I intentionally leave a stale value in Route53 the format of my error is different than yours. I do not see the \\ before the two quotes.

I don't type any quotes when I enter the value manually into the TXT value. I let Route53 do that. Could you be using a "funny" quote which requires the escape chars?

That said, I am using certbot to test so maybe it just formats the message differently.

3 Likes
10

Yes, Route53 does add the quotes for me, I only need to put them myself if I use the Route53 API, in both cases I get the same error.

I didn't parse the previous error message, parsing it the \\ is not there

{
  type: 'dns-01',
  status: 'invalid',
  error: {
    type: 'urn:ietf:params:acme:error:unauthorized',
    detail: 'Incorrect TXT record "ph-fuQOgWCC9VeqXIVYnor-vfx1WzIcxG3jVNK3191o" found at _acme-challenge.auth.runningplanandtrack.com',
    status: 403
  },
  url: 'https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/2177871348/7gJ0fw',
  token: 'ph-fuQOgWCC9VeqXIVYnor-vfx1WzIcxG3jVNK3191o',
  validated: '2022-04-13T18:56:04Z'
}
1 Like
11

@franciscofabian Reading Osiris note carefully he says client. Given the DNS TXT record looks fine ... did you experiment with the token value format you sent to LE server? Perhaps an extra quote gets stripped from error message giving the illusion it was ok?

Sorry I do not have a good way to test this as I don't do client dev myself. Someone who does is likely to find this. I'm going to move it to that topic section to draw attn.

2 Likes
12

I think it will be helpful if you read over the DNS challenge part of RFC8555 again carefully.

token does not go directly into the DNS TXT record.

You take the token from the challenge, and then:

  1. Derive the key authorization by concatenating it to your JWK thumbprint
  2. Calculate the SHA-256 digest of the value from (1)
  3. Encode the value from (2) using base64url

... then put that in the DNS TXT record.

11 Likes
13

@_az Thanks! I completely overlooked that part of the specification. It works now :slight_smile:

2 Likes
14

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