# Certbot webroot timeout issue when request new certificate

**URL:** <https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767>\
**Category:** Help\
**Created:** [November 21, 2017, 1:52pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767 "2017-11-21T13:52:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![an-ky](https://avatars.discourse-cdn.com/v4/letter/a/90db22/32.png) [@an-ky](https://community.letsencrypt.org/u/an-ky)\
**Post date:** [November 21, 2017, 1:52pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/1 "2017-11-21T13:52:51Z")

</div>

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](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: [feros.fza.hs-kempten.de](http://feros.fza.hs-kempten.de)

I ran this command: certbot certonly --debug --test-cert --webroot -w /var/www/feros/ -d [feros.fza.hs-kempten.de](http://feros.fza.hs-kempten.de)

It produced this output:  
Saving debug log to /var/log/letsencrypt/letsencrypt.log  
Starting new HTTPS connection (1): [acme-staging.api.letsencrypt.org](http://acme-staging.api.letsencrypt.org)  
Obtaining a new certificate  
Performing the following challenges:  
http-01 challenge for [feros.fza.hs-kempten.de](http://feros.fza.hs-kempten.de)  
Using the webroot path /var/www/feros for all unmatched domains.  
Waiting for verification…  
Cleaning up challenges  
Unable to clean up challenge directory /var/www/feros/.well-known/acme-challenge  
Traceback (most recent call last):  
File “/usr/bin/certbot”, line 11, in   
load\_entry\_point(‘certbot==0.10.2’, ‘console\_scripts’, ‘certbot’)()  
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 849, in main  
return config.func(config, plugins)  
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 626, in obtain\_cert  
action, \_ = \_auth\_from\_available(le\_client, config, domains, certname, lineage)  
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 107, in \_auth\_from\_available  
lineage = le\_client.obtain\_and\_enroll\_certificate(domains, certname)  
File “/usr/lib/python2.7/dist-packages/certbot/client.py”, line 291, in obtain\_and\_enroll\_certificate  
certr, chain, key, \_ = self.obtain\_certificate(domains)  
File “/usr/lib/python2.7/dist-packages/certbot/client.py”, line 262, in obtain\_certificate  
self.config.allow\_subset\_of\_names)  
File “/usr/lib/python2.7/dist-packages/certbot/auth\_handler.py”, line 77, in get\_authorizations  
self.\_respond(resp, best\_effort)  
File “/usr/lib/python2.7/dist-packages/certbot/auth\_handler.py”, line 134, in \_respond  
self.\_poll\_challenges(chall\_update, best\_effort)  
File “/usr/lib/python2.7/dist-packages/certbot/auth\_handler.py”, line 198, in \_poll\_challenges  
raise errors.FailedChallenges(all\_failed\_achalls)  
FailedChallenges: Failed authorization procedure. [feros.fza.hs-kempten.de](http://feros.fza.hs-kempten.de) (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching [http://feros.fza.hs-kempten.de/.well-known/acme-challenge/\_XJccXCJnkgUs824FGYZMYImXbaZUbh02v5NkF2dolA:](http://feros.fza.hs-kempten.de/.well-known/acme-challenge/_XJccXCJnkgUs824FGYZMYImXbaZUbh02v5NkF2dolA:) Timeout

```
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: feros.fza.hs-kempten.de
   Type: connection
   Detail: Fetching
   http://feros.fza.hs-kempten.de/.well-known/acme-challenge/_XJccXCJnkgUs824FGYZMYImXbaZUbh02v5NkF2dolA:
   Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

```

My web server is (include version):  
Server version: Apache/2.4.10 (Debian)  
Server built: Nov 28 2015 14:05:48

The operating system my web server runs on is (include version):  
PRETTY\_NAME="Debian GNU/Linux 8 (jessie)"  
NAME="Debian GNU/Linux"  
VERSION\_ID="8"  
VERSION="8 (jessie)"  
ID=debian  
HOME\_URL="[http://www.debian.org/](http://www.debian.org/)"  
SUPPORT\_URL="[http://www.debian.org/support](http://www.debian.org/support)"  
BUG\_REPORT\_URL=“[https://bugs.debian.org/](https://bugs.debian.org/)”

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

Tailing the log of apache parallel to execute the above command to issue a certificate shows  
`52.29.173.72 - - [21/Nov/2017:14:41:04 +0100] "GET /.well-known/acme-challenge/_XJccXCJnkgUs824FGYZMYImXbaZUbh02v5NkF2dolA HTTP/1.1" 200 310 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"`  
Which IMHO cleary states that the Let’s encrpypt server is actually able to request and get the challenge. I’m completely out of ideas.

Furthermore I put a file `test` in `.well-known/acme-challenge` which gets displayed when accessing in a browser through  
[http://feros.fza.hs-kempten.de/.well-known/acme-challenge/test](http://feros.fza.hs-kempten.de/.well-known/acme-challenge/test)

Any help is appreciated,  
thanks in advance

---

<div class="post-metadata">

**Author:** ![bytecamp](https://avatars.discourse-cdn.com/v4/letter/b/54ee81/32.png) [@bytecamp](https://community.letsencrypt.org/u/bytecamp)\
**Post date:** [November 21, 2017, 2:14pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/2 "2017-11-21T14:14:52Z")

</div>

How often did you try? Did you retry at least once?

---

<div class="post-metadata">

**Author:** ![an-ky](https://avatars.discourse-cdn.com/v4/letter/a/90db22/32.png) [@an-ky](https://community.letsencrypt.org/u/an-ky)\
**Post date:** [November 21, 2017, 2:16pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/3 "2017-11-21T14:16:31Z")

</div>

About six to eight times

---

<div class="post-metadata">

**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\
**Post date:** [November 21, 2017, 4:43pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/4 "2017-11-21T16:43:30Z")

</div>

> [@an-ky](#):
>
> Which IMHO cleary states that the Let’s encrpypt server is actually able to request and get the challenge.

Not necessarily (at least while you're using the staging server) - see [Validating challenges from multiple network vantage points](https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955)

Is it possible that your server or firewall is blocking connections from certain IP addresses or ranges?

---

<div class="post-metadata">

**Author:** ![an-ky](https://avatars.discourse-cdn.com/v4/letter/a/90db22/32.png) [@an-ky](https://community.letsencrypt.org/u/an-ky)\
**Post date:** [November 22, 2017, 12:48pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/5 "2017-11-22T12:48:34Z")

</div>

@jmorahan thanks for pointing out that staging tries to validate from different vantage points. The firewall indeed blocked access by regions so we removed the rules and it worked.

[edit]  
Alas, it only worked with staging, the production server still timeouts. Interestingly now I don’t get any request logged by apache but when issueing a stage certificate it is properly validated.

```auto
certbot certonly --staging --webroot -w /var/www/feros -d feros.fza.hs-kempten.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/feros.fza.hs-kempten.de.conf)

What would you like to do?
-------------------------------------------------------------------------------
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for feros.fza.hs-kempten.de
Using the webroot path /var/www/feros for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/feros/.well-known/acme-challenge
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/feros.fza.hs-kempten.de/fullchain.pem. Your
   cert will expire on 2018-02-20. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"

```

```auto
 certbot certonly --webroot -w /var/www/feros -d feros.fza.hs-kempten.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/feros.fza.hs-kempten.de.conf)

What would you like to do?
-------------------------------------------------------------------------------
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for feros.fza.hs-kempten.de
Using the webroot path /var/www/feros for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/feros/.well-known/acme-challenge
Failed authorization procedure. feros.fza.hs-kempten.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://feros.fza.hs-kempten.de/.well-known/acme-challenge/4e8NzRs5reaVzAjylA0lQzTBGBQV1Kl0QF6sEwJ13hc: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: feros.fza.hs-kempten.de
   Type: connection
   Detail: Fetching
   http://feros.fza.hs-kempten.de/.well-known/acme-challenge/4e8NzRs5reaVzAjylA0lQzTBGBQV1Kl0QF6sEwJ13hc:
   Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

```

Any ideas?

---

<div class="post-metadata">

**Author:** ![jmorahan](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jmorahan/32/1873_2.png) [@jmorahan](https://community.letsencrypt.org/u/jmorahan)\
**Post date:** [November 22, 2017, 4:08pm UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/6 "2017-11-22T16:08:55Z")

</div>

I can only make the obvious suggestion that perhaps the production server is trying to validate from yet another different vantage point? Are you sure you’re not still blocking something?

---

<div class="post-metadata">

**Author:** ![an-ky](https://avatars.discourse-cdn.com/v4/letter/a/90db22/32.png) [@an-ky](https://community.letsencrypt.org/u/an-ky)\
**Post date:** [November 23, 2017, 7:19am UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/7 "2017-11-23T07:19:01Z")

</div>

Yeah, an we have a further problem, that our firewall reorders its rules on a nightly basis so the geo-ip based blockes are enabled the next day. We need to further investigate in this issue. For know I’ll accept your solution @jmorahan, many thanks

---

<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:** [December 23, 2017, 7:19am UTC](https://community.letsencrypt.org/t/certbot-webroot-timeout-issue-when-request-new-certificate/46767/8 "2017-12-23T07:19:06Z")

</div>

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