I’ve looked at all the current topics however none of them appear to address my issue. When attempting to access our outward facing site (this) one, I get a handshake error. This problem began a while back with no real warning or config change (seemingly overnight).
The address is live so feel free to make requests against it.
Does anyone have any idea what might be going on/how to fix it?
The relevant log lines are:
Dec 26 19:40:22 proxy caddy[14097]: Activating privacy features...2017/12/26 19:40:22 [NOTICE] There is already a certificate loaded for gitlab.freegeekvancouver.org, so certificate for
[gitlab.freegeekvancouver.org] will not service that name
Dec 26 19:40:22 proxy caddy[14097]: 2017/12/26 19:40:22 http://gitlab.freegeekvancouver.org
Dec 26 19:40:22 proxy caddy[14097]: https://gitlab.freegeekvancouver.org/
Dec 26 19:40:22 proxy caddy[14097]: 2017/12/26 19:40:22 https://gitlab.freegeekvancouver.org/
Dec 26 19:40:22 proxy caddy[14097]: 2017/12/26 19:40:22 https://gitlab.freegeekvancouver.org:4567/
The Caddyfile:
# This file is managed by puppet.
# Any changes are not guaranteed to be persistent.
https://gitlab.freegeekvancouver.org/ {
proxy / http://gitlab.shop.lan/ {
transparent
}
tls [REDACTED]@freegeekvancouver.org {
dns cloudflare
}
gzip {
ext .js .css
}
request_id
header / {
# Enable cross-site filter (XSS) and tell browser to block detected attacks
X-XSS-Protection "1; mode=block"
# Prevent some browsers from MIME-sniffing a response away from the
# declared Content-Type
X-Content-Type-Options "nosniff"
# Disallow the site to be rendered within a frame (clickjacking
# protection)
X-Frame-Options "DENY"
Request-Id {request_id}
}
}
Is that the entire Caddyfile, and is the process being started anew (or is it being reloaded like with SIGUSR1?) And how are you running Caddy? Command line args, etc. Your logs show a site at port 4567 so I suspect you’re not giving the full picture here.
I’ve tried both. I have the same problem getting rid of all the other unrelated Caddyfiles (there’s an import statement in the main Caddyfile). I’m not somewhere where I can copy and paste the result but I remember from earlier that if you use curl on https://gitlab.freegeekvancouver.org/ you get an unknown protocol error.
Since that post I’ve removed the 4567 to no avail. The reason I haven’t included everything is cause there are a ton of internal, unrelated Caddyfiles.
`I also tested from our internal network and I was able to connect without a hitch. It shouldn’t matter what IP I’m connecting from though .
On Firefox I get a SSL_ERROR_RX_RECORD_TOO_LONG error.
From openssl s_client it looks like the site is serving a plaintext response on port 443 instead of a TLS handshake.
Since it sounds like your setup is very complicated, I would suggest stripping it down to the bare minimum, and rebuilding it from the ground up to debug it. The step which breaks it will tell you what causes it to act this way.
Figured it out. It was my dst-nat on my router… It was forwarding traffic destined for port 80 and 443 to port 80 on my host. Nothing related to caddy after all.
.