1. Caddy version (caddy version
):
$ caddy version
v2.2.2 h1:Ha3bvEvkb/GLGEX648/qI5zTt6uJCnfQhZHmZBxhzDY=
2. How I run Caddy:
Caddy is running as a reverse proxy over a set of applications, and is configured for local_certs to provide TLS (The solution is internal only). Clients are connecting via current chrome browser.
The installation is on a raspberry pi running raspbian lite OS (details below).
a. System environment:
Linux pidev 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME=“Raspbian GNU/Linux 10 (buster)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“10”
VERSION=“10 (buster)”
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
$ openssl version
OpenSSL 1.1.1d 10 Sep 2019
Windows 10 desktop client running google chrome Version 87.0.4280.88 (Official Build) (64-bit)
b. Command:
sudo systemctl start caddy
c. Service/unit/compose file:
# caddy.service
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
User=caddy
Group=caddy
#plugin modified caddy build for auth-portal and associated plugins
#/usr/bin/caddy now linked to /opt/caddy/releases/[current build]
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
#ExecStart=/opt/caddy/bin/caddy_linux_arm7_custom run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
#ExecReload=/opt/caddy/bin/caddy_linux_arm7_custom reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
{
storage file_system {
root /opt/caddy/storage
}
local_certs
http_port 80
https_port 443
}
https://demo-mguard.int.example.com, https://10.252.252.20 {
# caddy-auth-portal with local db config
log {
level INFO
format console
output file /var/log/caddy/caddy.log
}
# caddy auth portal login
route /auth* {
auth_portal {
path /auth
backends {
local_backend {
method local
path /opt/caddy/assets/conf/local/auth/user_db.json
realm local
}
}
jwt {
token_name access_token
token_secret AnExampleSecretString123
}
ui {
links {
"Elite Manager" /
}
}
}
}
route /login {
reverse_proxy http://localhost:1081
}
route /ui/* {
jwt {
enable claim headers
}
reverse_proxy http://localhost:1880
}
route /gr/* {
jwt {
enable claim headers
}
reverse_proxy http://localhost:3000
}
route /version* {
respond * "2.0.0-a" 200
}
# custom webapp running on port 1080 route
route /* {
jwt {
primary yes
trusted_tokens {
static_secret {
token_name access_token
token_secret AnExampleSecretString123
}
}
enable claim headers
}
reverse_proxy http://localhost:1081
}
}
3. The problem I’m having:
When using the local certs option of caddy for TLS, the certificate issued appears to be triggering a severe response that is beyond the normal “untrusted certificate” process a user has to go through when dealing with selfsigned/untrusted certs. In this case the broswer does not allow the user to “connect anyways” so the user can never fully connect through the proxy.
These (apparently new?) chrome TLS warnings do not allow a user to bypass the “unsecure” connection with the following warning, there is no visible way in the web page to proceed. Attempting to clear HSTS for the domain has no impact. The same alert takes place attempting to connect via IP or FQDN. Whatever is triggering the response in the browser is making the local certs implementation almost unusable?
4. Error messages and/or full log output:
demo-mguard.int.example.com normally uses encryption to protect your information. When Google Chrome tried to connect to demo-mguard.int.example.com this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be demo-mguard.int.example.com, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
You cannot visit demo-mguard.int.example.com right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.
(Note it never works)
5. What I already tried:
I’ve examined the certificate being presented with ‘openssl s_client -connect hostname:port | openssl x509 -noout -txt’ to check the certificate, I see the san and no subject DN being which I understand is fine. I’m going to set up wireshark to examine the TLS session setup as well… but wanted to get this discussion started.
I have read the discussions around IP address based HTTPS URL’s and the issue that the caddy has with providing proper response to SSL_get_servername when IP is used, but in our case we went back and configured FQDN and host file entries on the nodes in question (server, client) and are still getting the same harsh dead end on TLS warnings in latest chrome.
I did identify a way to bypass this in chrome by literally clicking in the middle of the page and typing (without quotes)
thisisunsafe
And then chrome whitelists the site for the current session until chrome is restarted. But obviously that is not a usable solution. (thanks stackoverflow!)
6. Links to relevant resources:
where I found where to get past the warning in chrome (not exact same issue, but still provides bypass that allows this to work)