Unable to update challenge :: authorization must be pending

Help
#1

My domain is: dfkunde.de

I ran this command: I'm using the C# library Certes to call the staging ACME v2 API, so no "command" here.

It produced this output: Fail to load resource from 'https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/164529708/qp56Dg'. urn:ietf:params:acme:error:malformed: Unable to update challenge :: authorization must be pending

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): I wrote the control panel myself.

I'm confused about the process. The last thing I've learned is that starting the challenge doesn't mean it's succeeded. It can reply with "give me more time" (Pending) and I see this once before it replies with an error. And according to the Certes examples (and what has worked in a separate test application) I can immediately call the finalize method and get a certificate. But in this whole setup, it doesn't work. I have no idea why. (Actually I didn't need any time in my test app, calling Validate and then immediately Generate just worked fine a few times. Is it much slower today than 2 days ago?)

I'm requesting a normal certificate (not wildcard) for two domains, dfkunde.de and the www subdomain. I request DNS challenge and get two challenges. I add them to my DNS, wait until primary and secondary nameserver resolve them all, and then validate them. When all challenges are valid, I proceed. And that fails now.

Actually I need this to be working pretty soon as it's the last part of my server migration. I previously used Certbot but that isn't available anymore if you don't agree to using snap, and I found it would be better to integrate the process into my control panel instead of hacking with external client software that doesn't know anything about my server environment.

Can you please explain, in simple words (ie. not RFC language), what steps I must perform for a DNS validation? I know of these:

  • Start order
  • Get authorisations
  • Get DNS challenges
  • Write TXT records to DNS, wait for resolving
  • Validate all challenges, expect "valid" response, otherwise retry (I retry every 10s)
  • Finalise order and download certificate (Certes combines these as Generate)
2 Likes
#2

You get one attempt to respond to each authorization.

If you take a look at https://acme-staging-v02.api.letsencrypt.org/get/authz-v3/164529708, you will see that the authorization is in a state of invalid:

DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.dfkunde.de - check that a DNS record exists for this domain

Once it's in this state, you can't respond to it again. You must abandon the order.

This error suggests that you are trying to respond to the authorization multiple times.

4 Likes
#3

I found that I made a mistake in setting up the DNS records. For wildcard certificates, like dfkunde.de and *.dfkunde.de, all records go to the same place, that's simple. Adding www.dfkunde.de is impossible because it is rejected as redundant with the wildcard. I consider this wrong because explicitly naming a domain has wider client compatibility than relying on the wildcard. But that's a different topic.

When ordering for dfkunde.de and www.dfkunde.de, I need to put the TXT records in different places though. And this raises another question:

How do I know which challenge is for which domain? I can't find any data in the challenge objects. Is it guaranteed to be the same order as the domains were added to the order? Or will I have to look it up somewhere?

I'm also still puzzled about the namings. It looks like an authorisation and a challenge refers to the same thing. Or is it just an issue of the Certes library?

2 Likes
#4

The authorization object contains the domain name for which the DNS challenge must be established.

2 Likes
#5

Thank you, everything is working now!

3 Likes
#6

This isn't wrong. The DNS RFCs mandate this and(Confused with CNAME rules) Let's Encrypt will also refuse to add subdomains which would be included in the wildcard hostname.

Also, I'm not aware of any TLS client not capable of understanding wildcard certificates.

2 Likes
#7

We've observed issues with an MQTT client library for .NET Core 2.2 or 3.1 running on Windows or Linux (can't remember which combination it was) that worked with a regular certificate but considered a wildcard certificate invalid. Other combinations worked, though, so it might be an old bug (not too old).

Oh, and is Wikipedia right that wildcards only apply to one level of subdomains, i.e. anything except a point (".")?

1 Like
#8

Yes, a wildcard is only valid for one label, the only allowed place is the utmost left label and you can only have one wildcard in a hostname. So *.*.example.com and foo.*.example.com are invalid and *.example.com won't match foo.bar.example.com.

MQTTnet by any chance?

1 Like
#9

Yes, that's the library. But we assume that it simply relies on the underlying OS' certificate validation check.

1 Like
#10

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