Challenges stay at pending state, ACME client locks up

Help
1

My domain is:
webchat.alphachat.net

I ran this command:
/usr/local/dehydrated/dehydrated --cron --keep-going --config /etc/dehydrated/config-rsa

It produced this output:
No output beyond “Responding to challenge”, challenge status URI says pending and this never changes, but I can curl the challenge token URI and receive the expected token value immediately from 10 different machines across the world with IPv4 and IPv6.

The latest challenge token URI is: http://webchat.alphachat.net/.well-known/acme-challenge/pqYgNvZqbALibzEXvuiPoHfW5yarIiNG9a9cyEPFWTE
The latest challenge status URI is: https://acme-v01.api.letsencrypt.org/acme/challenge/edS4Qv_rbeG5oeNPF3IrBm3HgIeiRuExE9iyW-CN6q0/255916479

My operating system is: Gentoo Hardened amd64 nomultilib
My webserver is: nginx 1.11.5

2

I should mention it works fine on the staging API (literally just changing the CA configuration option, nothing else).

3

Does the log show anything ?

It’s probably worth raising an issue on the dehydrated github page.

4

The webserver access log shows that the last request for a challenge token was several days ago.

5

and dehydrated just hangs, waiting at that point ?

6

It waits until the challenge succeeds or fails, yes. So being stuck in pending is a problem.

7

Unfortunately I don’t use dehydrated, and it doesn’t seem to have a debug option to give more information that I’d recognise / use to help find the cause of the issue.

The best bet may be the dehydrated github ( so you can resolve this with the script author).

The only other thing I can suggest is trying one of the other scripts that does give detailed debug info, which may help.

8

I’ve read the relevant part of the client source code; it just does an HTTP request to the status URI until it succeeds or fails. LE isn’t requesting the token from the web server. I don’t believe this is a client-side problem.

9

Possibly - I have no access to letsencrypt servers though to be able to see / debug - so I can only debug from the client side info :wink: From my perspective I’d want to see the complete requests for the domain. My guess is that a different method ( perhaps DNS ? ) is validated for your account already, hence the LE isn’t asking you to validate since you are already validated. As such it would be a client issue, as it should check if it’s already validated.

A way to check that would be to change your account key - since for a different account key, it would not be validated, and LE would check the validation. If that completes, than I suspect that’s the issue. Without the full responses from the ACME server in the request for the domain though, it’s impossible for me to say.

10

The thread Upcoming change: valid authz reuse is information about what I suspect is the most likely cause of your issue.

1 Like
11

The complete output is at https://paste.debian.net/plainh/0e33f182 – it issues me a challenge when the client requests one, so I don’t really know what to say.

12

I don’t think that’s the problem either, because that mentions it will still allow updates to the authorization for clients to continue behaving normally and they turned it on in staging first, which my client works with.

13

The request for validation from the ACME server should return a JSON object that looks like

{
  "identifier": {
    "type": "http",
    "value": "domain.com"
  },
  "status": "valid",
  "expires": "2016-10-23T16:53:20.241829464Z",
  "challenges": [
    {
      "type": "dns-01",
      "status": "valid",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/hJWVsbSbgJeOGKVYjeyGyc6e2QkZ_9MDu07qJdXi_s8/16007051",
      "token": "iLJm0vEk4k28puP6Zrg5VKJrM49cdZSxekACDNAn26Y"
    },
    {
      "type": "tls-sni-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/hJWVsbSbgJeOGKVYjeyGyc6e2QkZ_9MDu07qJdXi_s8/16007052",
      "token": "rCbkEg8LR5Re1HV3OL6dVgQRccQ7qXMwMaEYoDEsvkg"
    },
    {
      "type": "http-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/hJWVsbSbgJeOGKVYjeyGyc6e2QkZ_9MDu07qJdXi_s8/16007053",
      "token": "PX_etlJxX8ab7mecY5nQdxyAsoXkA1vBB1DVrpcyhNo"
    }
  ],
  "combinations": [
    [
      2
    ],
    [
      0
    ],
    [
      1
    ]
  ]
}

The response states it is “valid” but for http-01 it’s “pending”. In a case like this, if the client only checks what the type “http-01” is, it will always remain as pending - because it has responded that it’s valid for your account, for that domain. the ACME server will never check the http token - because it doesn’t need to … and the client will wait forever ( if it doesn’t check the overall validity )

Did you at some point in thepast validate the domain to obtain a certificate by a different method ?

1 Like
14

see Stuck at "Pending" when using DNS challenge for the same issue describe ( although there, it was stuck in pending for DNS) - and what the fix on the client side was ( in that case it was GetSSL, which is a client I wrote.

1 Like
15

Ah. That explains it. I did initially request these certificates with ZeroSSL and dns-01 validation.

16

It would be useful if you could raise it as an issue for dehydrated, so the code can be fixed.

17

Will do!

(Insert arbitrary amount of text to get past 20 character requirement for posting here)

2 Likes
18

Issue opened as https://github.com/lukas2511/dehydrated/issues/297

3 Likes
19

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