Problem With SSL Handshake On "www" Domain

Help
1

I have the following Caddyfile:

fistbump.io:80 {
    tls off

    redir 301 {
        if {scheme} is http
        /  https://fistbump.io{uri}
    }

    root /home/cloud/app/public


    gzip
    fastcgi / 127.0.0.1:9000 php

    limits {
        body 50mb
    }

    rewrite {
        to {path} {path}/ /index.php?{query}
    }
}

fistbump.io:443 {
    tls {
        max_certs 1
    }

    redir 301 {
        if {scheme} is http
        /  https://fistbump.io{uri}
    }

    root /home/cloud/app/public


    gzip
    fastcgi / 127.0.0.1:9000 php

    limits {
        body 50mb
    }

    rewrite {
        to {path} {path}/ /index.php?{query}
    }
}

www.fistbump.io:80 {
    tls off

    redir 301 {
        /  https://fistbump.io{uri}
    }
}

www.fistbump.io:443 {
    tls {
        max_certs 1
    }

    redir 301 {
        /  https://fistbump.io{uri}
    }
}

The on-demand SSL is working great for the naked “fistbump.io” domain; however, I get a handshake error when typing https://www.fistbump.io into my browser:

2017/06/19 14:26:23 http: TLS handshake error from 162.158.78.172:22682: [www.fistbump.io] failed to get certificate: acme: Error 400 - urn:acme:error:tls - remote error: tls: handshake failure
Error Detail:
	Validation for www.fistbump.io:443
	Resolved to:
		104.24.115.140
		104.24.114.140
		2400:cb00:2048:1::6818:728c
		2400:cb00:2048:1::6818:738c
	Used: 104.24.115.140

However, what confuses me is that my DNS is all managed through Cloudflare and those are the exact same IPs used by the naked domain, so it should be resolving fine.

Is there something wrong with my configuration I am missing?

2

I’m not sure why you’re getting the handshake error, but I don’t think you need to worry about redirecting non-ssl traffic. I think Caddy will just do that for you. My Caddyfile looks something like this:

example.com, www.example.com {

    log /path/to/caddy.log
    root /path/to/www/

    rewrite { ... }
    tls foo@example.com
}

Not sure if that helps or not.

3

@bkmontgomery is right, you don’t have to redirect the HTTP traffic. As long as you use automatic HTTPS, the redirect is done for you.

Are you sure the www. domain is configured (DNS, Cloudflare, etc.) the same as the naked domain? Try stripping out every possible middleman like Cloudflare and make sure it’s all working correctly… when I go to http://104.24.115.140/ I get “direct IP access not allowed”…

4

I deleted the server.

Yes, they were configured the same. I will set everything back up again.

5

I’m suspicious it is something Cloudflare is doing. I provisioned a new stack just using Route 53 for the DNS and it seem to be working (using staging CA on this one):

https://verbler.com
https://www.verbler.com

6

Hmm okay. That’s good news, probably Cloudflare interfering then…

7

CloudFlare are great, if inflexible and somewhat meddlesome sometimes. It wouldn’t surprise me if the issue was CloudFlare related.

8

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