1. Caddy version (caddy version
): v2.0.0 – commit id: e051e119d1dff75972ed9b07cf97bbb989ba8daa
2. How I run Caddy:
Using a systemd service as defined below.
a. System environment:
Archlinux LXC container on Proxmox VE 6.2-4
b. Command:
N/A if restarting the containerOR
# systemctl start caddy
c. Service/unit/compose file:
[Unit]
2 Description=Caddy Web Server
3 Documentation=https://caddyserver.com/docs/
4 After=network.target
5
6 [Service]
7 User=http
8 Group=http
9 ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile --environ
10 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
11 TimeoutStopSec=5s
12 LimitNOFILE=1048576
13 LimitNPROC=512
14
15 # Hardening options
16 PrivateTmp=true
17 ProtectSystem=strict
18 PrivateDevices=true
19 ProtectHome=true
20 ReadWritePaths=/var/lib/caddy /var/log/caddy
21 AmbientCapabilities=CAP_NET_BIND_SERVICE
22 CapabilityBoundingSet=CAP_NET_BIND_SERVICE
23 NoNewPrivileges=true
24 ProtectKernelTunables=true
25 ProtectKernelModules=true
26 ProtectControlGroups=true
27 LockPersonality=true
28
29
30 [Install]
31 WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
{
acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}
(cloudflare) {
tls {
dns cloudflare $CLOUDFLARE_AUTH_TOKEN
}
}
bw.tabala.com {
import cloudflare
log {
output file /var/log/caddy/caddy.log {
roll_size 512mb
roll_keep 5
roll_keep_for 168h
}
}
encode gzip
header / {
# Enable HTTP Strict Transport Security (HSTS)
#Strict-Transport-Security "max-age=31536000;"
# Enable cross-site filter (XSS) and tell browser to block detected attacks
X-XSS-Protection "1; mode=block"
# Disallow the site to be rendered within a frame (clickjacking protection)
X-Frame-Options "DENY"
# Prevent search engines from indexing (optional)
X-Robots-Tag "none"
# Server name removing
-Server
}
# The negotiation endpoint is also proxied to Rocket
reverse_proxy /notifications/hub/negotiate 192.168.1.25:80
# Notifications redirected to the websockets server
reverse_proxy /notifications/hub 192.168.1.25:3012
# Proxy the Root directory to Rocket
reverse_proxy 192.168.1.25:80
#reverse_proxy * 192.168.1.25:8000
}
I got the header section and the proxy configuration setup from the Caddy 2 example from this link
3. The problem I’m having:
I cannot get to the bitwarden web-vault nor can i access the reverse proxy server which would then forward me to the bitwarden service using HTTPS.
Questions
- What DNS records and their values do I need in my Cloudflare account to setup on my domain so that I can access the reverse proxy which would then forward me to the correct service based on what I type in the address bar?
- Should I use wildcard SSL cert so that the same cert can be used for all the services on my network? Which DNS records in my Cloudflare account are required in this case?
- Or Should I use separate certs for each service?
AIM : to simply type in the address bar (while on the LAN)
- cloud - so that it would take me to my self-hosted Nextcloud instance
- nas - so that it would take me to my nas login page etc.
4. Error messages and/or full log output:
I don’t see any logs generated under /var/log/caddy
Here’s what #systemctl status caddy shows:
service - Caddy Web Server
3 Loaded: loaded (/usr/lib/systemd/system/caddy.service; enabled; vendor preset: disabled)
4 Active: active (running) since Tue 2020-05-26 23:03:31 UTC; 2s ago
5 Docs: https://caddyserver.com/docs/
6 Main PID: 4237 (caddy)
7 Tasks: 7 (limit: 4915)
8 Memory: 13.9M
9 CGroup: /system.slice/caddy.service
10 `-4237 /usr/bin/caddy run --config /etc/caddy/Caddyfile --environ
11
12 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] acme: Obtaining bundled SAN certificate given a CSR
13 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/59521055
14 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] acme: Could not find solver for: tls-alpn-01
15 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] acme: Could not find solver for: http-01
16 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] acme: use dns-01 solver
17 May 26 23:03:32 reverseproxy caddy[4237]: 2020/05/26 23:03:32 [INFO] [bw.tabala.com] acme: Preparing to solve DNS-01
18 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] [bw.tabala.com] acme: Trying to solve DNS-01
19 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] [bw.tabala.com] acme: Checking DNS record propagation using [192.168.1.1:53]
20 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] Wait for propagation [timeout: 1m0s, interval : 2s]
21 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] [bw.tabala.com] acme: Waiting for DNS record propagation
22 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] [bw.tabala.com] acme: Checking DNS record propagation using [192.168.1.1:53]
23 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] Wait for propagation [timeout: 1m0s, interval: 2s ]
24 May 26 23:03:33 reverseproxy caddy[4237]: 2020/05/26 23:03:33 [INFO] [bw.tabala.com] acme: Waiting for DNS record propagation.
25 May 26 23:03:35 reverseproxy caddy[4237]: 2020/05/26 23:03:35 [INFO] [bw.tabala.com] acme: Waiting for DNS record propagation.
26 May 26 23:03:43 reverseproxy caddy[4237]: 2020/05/26 23:03:43 [INFO] [bw.tabala.com] The server validated our request
27 May 26 23:03:43 reverseproxy caddy[4237]: 2020/05/26 23:03:43 [INFO] [bw.tabala.com] acme: Cleaning DNS-01 challenge
28 May 26 23:03:43 reverseproxy caddy[4237]: 2020/05/26 23:03:43 [INFO] [bw.tabala.com] acme: Validations succeeded; requesting certificates
29 May 26 23:03:44 reverseproxy caddy[4237]: 2020/05/26 23:03:44 [INFO] [bw.tabala.com] Server responded with a certificate.
30 May 26 23:03:44 reverseproxy caddy[4237]: 2020/05/26 23:03:44 [INFO][bw.tabala.com] Certificate obtained successfully
31 May 26 23:03:44 reverseproxy caddy[4237]: 2020/05/26 23:03:44 [INFO][bw.tabala.com] Obtain: Releasing lock
5. What I already tried:
Backstory: This all started with my Bitwarden web vault not being accessible after a Firefox update. I got errors saying:
Cannot read property 'importKey' of null
Apparently this post seemed to suggest it was a browser issue where the browser no longer supported HTTP access to the bitwarden service. So in enabling HTTPS for bitwarden, I thought I might as well also implement a reverse proxy so that I don’t have to remember the ports for all the various services that I have on my network. Enter caddy, since it supported easy configuration for Let’s Encrypt. Being new to this whole thing, it didn’t matter if I chose Apache, Nginx or caddy.
I went ahead and bought a domain for this purpose and since caddy didn’t have a dns provider for my domain registrar’s name servers, I switched over to Cloudflare. After installing caddy on my Archlinux container using this PKGBUILD from caddyserver/dist/archlinux , I built a new binary using the xcaddy command below and copied the newly built caddy binary to /usr/bin/caddy
xcaddy build --with github.com/caddy-dns/cloudflare
I don’t have anything hosted on my domain – if that matters. Maybe in the future I will buy a hosting package and put up a website there
I seemed to have picked an inopportune time to create a reverse proxy because caddy was in transition from v1 to v2. caddy was in the late betas at the time, so I went through the muck of various forum posts and incomplete (at that time) documentation to see how to create a Caddyfile for v2. After a lot of trial and error with various settings – some which happened to be from v1 and didn’t quite translate over to v2, I finally have that right and I can get the SSL certs from Let’s Encrypt by creating an ‘A’ record for bw and pointing it to my home’s WAN IP address.
Currently:
However, I use pfsense as my router and when I put in bw.tabala.com in the address bar (while being on the LAN), I get presented the NET::ERR_CERT_AUTHORITY_INVALID page. If I click Advanced and proceed I get the pfsense page with the following warning :
Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding
Try accessing the router by IP address instead of by hostname.
instead of being presented the bitwarden login page.
What DNS records do I need to set in my DNS provider, in order for me to get to the reverse proxy – which would then forward me to the correct service (bitwarden or guacamole, or syncthing etc.)?
Currently I am trying this only with bitwarden, but eventually I want the same reverse proxy to be able to handle all of the services on my network (8 LXC containers, 3 VMs, Proxmox host itself, separate FreeNAS box and 3 plugins on the FreeNAS box, & pfsense router). Some of them currently use self signed certs and some just work on HTTP – I was hoping to use Let’s Encrypt certs for all the services. That way I won’t have to remember the port numbers etc. and would aim to simply put in the address bar (while on the LAN)
cloud - so that it would take me to my self-hosted Nextcloud instance
nas - so that it would take me to my nas login page etc.
6. Links to relevant resources:
I read a lot of forum posts and links which eventually helped me get to a point where I am able to get the SSL certs correctly, but I don’t think they are relevant to the issue that I have now.