Failed authorization due to timeout, but port 443 is accessible

I am able to hit https://bookishfirst.com (our new domain) using an incorrect SSL certificate from a different domain, but it does produce a response. We serve other SSL domains on this same server so I know that 443 is open.

In addition to the below I’ve also checked the logs at /var/log/letsencrypt but didn’t find anything that seemed helpful.

My domain is: bookishfirst.com

I ran this command: certbot --apache

It produced this output:

Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for bookishfirst.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. bookishfirst.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

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

   Domain: bookishfirst.com
   Type:   connection
   Detail: 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): Apache 2.4

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

My hosting provider, if applicable, is: EC2

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

Although I can’t replicate the “timeout” error I did find DNS resolution a bit slower than expected.

And this may (or may not) help:
wget http://bookishfirst.com
–2017-07-31 16:24:50-- http://bookishfirst.com/
Resolving bookishfirst.com (bookishfirst.com)… 107.20.245.193
Connecting to bookishfirst.com (bookishfirst.com)|107.20.245.193|:80… connected.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: https://www.netgalley.com/ [following]
–2017-07-31 16:24:55-- https://www.netgalley.com/
Resolving www.netgalley.com (www.netgalley.com)… 107.20.245.193
Connecting to www.netgalley.com (www.netgalley.com)|107.20.245.193|:443… connected.
HTTP request sent, awaiting response… 200 OK

wget https://bookishfirst.com
–2017-07-31 16:25:16-- https://bookishfirst.com/
Resolving bookishfirst.com (bookishfirst.com)… 107.20.245.193
Connecting to bookishfirst.com (bookishfirst.com)|107.20.245.193|:443… connected.
ERROR: no certificate subject alternative name matches
requested host name ‘bookishfirst.com’.
To connect to bookishfirst.com insecurely, use `–no-check-certificate’.

We actually were having a server issue related to another site at precisely the time you were trying (hah). I will go back and give it another try shortly, though.

Should I have any particular SSL configuration prior to trying this, or will the tool do all of that for me?

Hi,

I am having an identical problem on a test server on AWS EC2 running Ubuntu 16.04 and Apache. I get the timeout error repeatedly but I can go to the web site and view the test page from any number of locations with no problems. When I run “sudo certbot --apache” I get:

I am just trying to test the CertBot installation process on a test AWS server before I install it on my production server.

Thanks,

Shivaji

I can’t connect to that server myself. How many different locations are you trying?

Tried from work, and also via my COX Cable service at home. If you ping it does it resolve for you? From the console of my production web server (which is hosted in Newark, NJ) I get this:
PING awstest.virginiawestern.edu (52.14.74.86) 56(84) bytes of data

It times out, which maybe because ICMP is turned off but I guess DNS is resolving properly as that is the correct external IP address for the server…

Thanks,
Shivaji

I get that same IP address, but no ICMP reply, and TCP connections to port 80 time out for me.

I think I found the problem. I was paranoid and had firewall rules setup to restrict access from my subnets at work and at home. You should be able to ping it and access the website now.

Thanks for your help,

Shivaji

I haven’t posted in this thread before, but for me, HTTP and HTTPS connections timed out before, and work now. :slightly_smiling_face:

Ping also works now, but i didn’t try it before.

Unfortunately for me I am still seeing the same issue (on the server I mentioned at the top of the thread). I’ve confirmed that ports 80 and 443 both produce a response, and have tried both with and without SSL configured prior to running certbot --apache.

Any ideas what I might be doing wrong?

I’m sorry. I was distracted by the other issue in this thread. :sweat:

What error are you getting at this time? What does Certbot output? The exact same “Timeout” error as before? What does /var/log/letsencrypt/letsencrypt.log say?

Is it correct that https://bookishfirst.com/ has the IP address 107.20.245.193 and is currently using an expensive Symantec (GeoTrust) certificate for netgalley.com?

I tried to attach the full log file here, but it won’t let me upload an attachment. So, the tail end of the log is:

2017-08-01 18:38:59,413:DEBUG:acme.client:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/nmItBKfb2ancI1cqpRxvP2V4_51ybTjkYp18z80HDFE.
2017-08-01 18:38:59,529:DEBUG:requests.packages.urllib3.connectionpool:"GET /acme/authz/nmItBKfb2ancI1cqpRxvP2V4_51ybTjkYp18z80HDFE HTTP/1.1" 200 1506
2017-08-01 18:38:59,530:DEBUG:acme.client:Received response:
HTTP 200
Content-Length: 1506
Strict-Transport-Security: max-age=604800
Boulder-Request-Id: poHdMXf5K0w_53_Zt1OEfasW8NDle02xBD0myBsD30A
Expires: Tue, 01 Aug 2017 18:38:59 GMT
Server: nginx
Connection: keep-alive
Link: <https://acme-v01.api.letsencrypt.org/acme/new-cert>;rel="next"
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Tue, 01 Aug 2017 18:38:59 GMT
X-Frame-Options: DENY
Content-Type: application/json
Replay-Nonce: 6xJw3HoESjFSd7PZO1odEqS2fPnRWW4sXOaPVg0PFls

{
  "identifier": {
    "type": "dns",
    "value": "bookishfirst.com"
  },
  "status": "invalid",
  "expires": "2017-08-08T18:38:49Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/nmItBKfb2ancI1cqpRxvP2V4_51ybTjkYp18z80HDFE/1662246173",
      "token": "9cJpzvMfOe0FJNZPdxkQQQ6RkpIunu4qVmIfIDODTCA"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/nmItBKfb2ancI1cqpRxvP2V4_51ybTjkYp18z80HDFE/1662246174",
      "token": "pr_HCboX7isKIDhy7tlTZYGQc-7vnfRr2pXwrcEcgx0"
    },
    {
      "type": "tls-sni-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "Timeout",
        "status": 400
      },
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/nmItBKfb2ancI1cqpRxvP2V4_51ybTjkYp18z80HDFE/1662246175",
      "token": "4VZEkwMDvfjAwh2eq_mQMhStDLhzzcEEEpGl2g72gdM",
      "keyAuthorization": "4VZEkwMDvfjAwh2eq_mQMhStDLhzzcEEEpGl2g72gdM.6Nzg6WIfDDK59H1DpedwWooinKObOIQ1Xt_w9pnU3u8",
      "validationRecord": [
        {
          "hostname": "bookishfirst.com",
          "port": "443",
          "addressesResolved": [
            "107.20.245.193"
          ],
          "addressUsed": "107.20.245.193",
          "addressesTried": []
        }
      ]
    }
  ],
  "combinations": [
    [
      0
    ],
    [
      2
    ],
    [
      1
    ]
  ]
}
2017-08-01 18:38:59,532:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: bookishfirst.com
Type:   connection
Detail: 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.
2017-08-01 18:38:59,532:INFO:certbot.auth_handler:Cleaning up challenges
2017-08-01 18:39:00,064:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.14.2', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 742, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 597, in run
    certname, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 82, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 344, in obtain_and_enroll_certificate
    certr, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 313, in obtain_certificate
    self.config.allow_subset_of_names)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 81, in get_authorizations
    self._respond(resp, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 138, in _respond
    self._poll_challenges(chall_update, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 202, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. bookishfirst.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

The IP address is correct at 107.20.245.193. Requesting https://bookishfirst.com should result in a certificate from bookish.com. If you hit https on the IP address, it would give you the one from netgalley.com. I had configured the bookishfirst.com host with the other certificate just so it would respond on 443, but I’ve also tried removing that entirely and the certbot --apache command gave the same error.

@cpu, can you see any reason why this particular challenge verification would time out from the data center network? It seems not to time out from here.

There’s nothing additional in the logs, just the same timeout. I can also connect to the resolved IP on 443 from my own network vantage point. I’ll ask someone from operations to investigate from one of the DCs.

From the DCs I am able to make a successfull connection to ports 80/443 on http://bookishfirst.com/.

Out of curiosity, can you try using certbot webroot via this command? The steps I would take are

  1. disable the ssl vhost
  2. reload Apache
  3. verify that connections to your http://bookishfirst.com:80 are working as intended
  4. run certbot via the command below
  5. enable the ssl vhost after you point to the correct certificate location
  6. reload apache
  7. test that https://bookishfirst.com:443 is working.
certbot certonly \
    --webroot \
    --webroot-path /path/to/your/htdocs/for/this/domain \
    --renew-by-default \
    --email whoever@example.com \
    --text \
    --agree-tos \
    -d www.bookishfirst.com \
    -d bookishfirst.com
1 Like

Awesome, that did it!

I configured a directory at /var/www/bookishfirst.com and then ran exactly this:

certbot certonly \
--webroot \
--webroot-path /var/www/bookishfirst.com \
--renew-by-default \
--email whoever@example.com \
--text \
--agree-tos \
-d bookishfirst.com

And that produced the proper certificate output in /etc/letsencrypt.

Thanks everybody for all the assistance with this.

2 Likes

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