# Challenges stay at pending state, ACME client locks up

**URL:** <https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188>\
**Category:** Help\
**Created:** [October 16, 2016, 12:49pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188 "2016-10-16T12:49:25Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 12:49pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/1 "2016-10-16T12:49:25Z")

</div>

My domain is:  
[webchat.alphachat.net](http://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](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](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

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:17pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/2 "2016-10-16T16:17:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:30pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/3 "2016-10-16T16:30:14Z")

</div>

Does the log show anything ?

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

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:30pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/4 "2016-10-16T16:30:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:32pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/5 "2016-10-16T16:32:40Z")

</div>

and dehydrated just hangs, waiting at that point ?

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:33pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/6 "2016-10-16T16:33:00Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:38pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/7 "2016-10-16T16:38:52Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:40pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/8 "2016-10-16T16:40:50Z")

</div>

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.

> <https://github.com/lukas2511/dehydrated/blob/master/dehydrated#L513-L522>

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:46pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/9 "2016-10-16T16:46:58Z")

</div>

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 😉 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.

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:51pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/10 "2016-10-16T16:51:25Z")

</div>

The thread [Upcoming change: valid authz reuse](https://community.letsencrypt.org/t/upcoming-change-valid-authz-reuse/16982) is information about what I suspect is the most likely cause of your issue.

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:51pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/11 "2016-10-16T16:51:34Z")

</div>

The complete output is at [https://paste.debian.net/plainh/0e33f182](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.

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 4:52pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/12 "2016-10-16T16:52:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 4:57pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/13 "2016-10-16T16:57:56Z")

</div>

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

```auto
{
  "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 ?

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 5:01pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/14 "2016-10-16T17:01:00Z")

</div>

see [Stuck at "Pending" when using DNS challenge](https://community.letsencrypt.org/t/stuck-at-pending-when-using-dns-challenge/19148) 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.

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 5:03pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/15 "2016-10-16T17:03:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [October 16, 2016, 5:05pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/16 "2016-10-16T17:05:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 5:06pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/17 "2016-10-16T17:06:57Z")

</div>

Will do!

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

---

<div class="post-metadata">

**Author:** ![aaronmdjones](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@aaronmdjones](https://community.letsencrypt.org/u/aaronmdjones)\
**Post date:** [October 16, 2016, 5:09pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/18 "2016-10-16T17:09:13Z")

</div>

Issue opened as [https://github.com/lukas2511/dehydrated/issues/297](https://github.com/lukas2511/dehydrated/issues/297)

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [November 15, 2016, 5:17pm UTC](https://community.letsencrypt.org/t/challenges-stay-at-pending-state-acme-client-locks-up/21188/19 "2016-11-15T17:17:24Z")

</div>

Closed on November 15, 2016, 5:17pm UTC

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