Client can't connect to website (nginx) which provide HTTPS-only


I didn’t found any related answer so i’m a little bit confused as well.

At last day of march i want to renew all certificates which are used by default.

Most of them succeeded but 2 (whole) websites failed with the above:

Here is one of them:

Type: connection
Detail: Could not connect to

Type: connection
Detail: Could not connect to

The difference between this and any other is, that this website redirect (301) all http:// requests to https:// by default. So there is no real http://… available.

If i create a Testfile called i can reach/download it - so there is no DNS/access/… error.

So i guess it’s related to the redirect or!?

I’m using NGINX…

Any ideas?!


Let’s Encrypt performed some network maintenance today (or rather yesterday) between 11PM and 12AM UTC:

Let’s Encrypt will be doing maintenance on it’s network during this time and there will likely be intermittent interruption of services.

Is it possible your renewal was just inside that window?

Redirecting to HTTPS is fine for http-01 validation, as long as the target URL serves the correct challenge token. Your SSL configuration doesn’t seem like it would cause any connection errors from the CA server either, so a temporary network error would be my best guess.


Nope, same error right now.

Yes, i can’t find any error on my web-configuration, so for me it seems like this is an REDIRECT-issue maybe!?

All other websites, with HTTP- and HTTPS-version works fine.


Redirects should work, and I have successfully issued certificates with a blanket HTTP-to-HTTPS-redirect in the past.

You could try this approach in your http server block:

server {
  listen 80;

  location / {
    return 301 https://$host$request_uri;

  location "/.well-known/acme-challenge" {
    root /var/www/html;

This should skip the redirect for anything starting with .well-known/acme-challenge. If this ends up working, there’s either a regression in the CA server software or the CA server’s TLS stack has some odd connectivity issue with your TLS configuration (which, to me, looks perfectly fine).



I attached the letsencrypt.txt (65.5 KB) for more verbosity.

There is a part like

2016-04-04 11:30:34,527:DEBUG:root:Received <Response [201]>. Headers: {‘Content-Length’: ‘779’, ‘Expires’: ‘Mon, 04 Apr 2016 11:30:36 GMT’, ‘Strict-Transport-Security’: ‘max-age=604800’, ‘Server’: ‘nginx’, ‘Connection’: ‘keep-alive’, ‘Link’: ‘;rel=“next”’, ‘Location’: ‘’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Mon, 04 Apr 2016 11:30:36 GMT’, ‘X-Frame-Options’: ‘DENY’, ‘Content-Type’: ‘application/json’, ‘Replay-Nonce’: ‘zARTL_QgCcVbc-RoLv_UP7cVXPFCb5ZoJNSUzBElpgg’}. Content: ‘{“identifier”:{“type”:“dns”,“value”:“”},“status”:“pending”,“expires”:“2016-04-11T11:30:36.113810412Z”,“challenges”:[{“type”:“tls-sni-01”,“status”:“pending”,“uri”:“",“token”:“Wyw2YWd-JyfTPNtoFphPIxupdc6Ii7BYl_YfjnaqAQU”},{“type”:“dns-01”,“status”:“pending”,“uri”:“”,“token”:“CBWhrlF0A-bY4fLOOsJ2FxbbM3Wq6537SO8gUlNS_S4”},{“type”:“http-01”,“status”:“pending”,“uri”:“”,“token”:“Q5nLjYUE4Mah3B9HaMIJPVSD6_82TvwQFJepykLG-Hk”}],"combinations”:[[0],[1],[2]]}’

Is there something around, maybe i’m “blocked” or a wrong cache is on letsencrypt-servers?


Or does it conflict with some headers i sent?


That log looks fine to me.

Your site is still redirecting to https://, though:

curl -v
*   Trying
* Connected to ( port 80 (#0)
> GET /.well-known/acme-challenge/foo HTTP/1.1
> Host:
> User-Agent: curl/7.43.0
> Accept: */*
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Mon, 04 Apr 2016 11:41:56 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Keep-Alive: timeout=20
< Location:

Double-check your nginx config for any other redirects that might cause this.

AFAIK, those are ignored for http-01 verification.


I edited this and now it WORKS.

So i’ve do this for all websites? Seems like redirects doesn’t work perfectly!?


Redirects don’t seem to be broken completely, but something specific to your config seems to break it. (I’ve tested it on another domain just now, and it worked).

For now, I’d recommend adding the new redirect logic for any sites where you’re getting this error.

@jsha: Any boulder logs you could check that might shed some light on this issue? I’ve seen similar issues once or twice, like this one, but I can’t find anything wrong with this particular TLS config (A+ on SSL Labs).


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