1. Caddy version (caddy version
):
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=
Built via xcaddy: ~/go/bin/xcaddy build --with github.com/caddy-dns/cloudflare --with github.com/hairyhenderson/caddy-teapot-module
2. How I run Caddy:
a. System environment:
Debian 10.4 Buster
b. Command:
Caddy usually maintained via systemd service but for testing, I am just executing it manually:
caddy run
d. My complete Caddyfile or JSON config:
{
#debug
}
##### START OF REVERSE PROXY SNIPPETS #####
(rp_nextcloud01) {
reverse_proxy http://nextcloud01.app.colo.1904.tech:80 {
header_down "X-Served-By" "Edge05"
flush_interval -1
}
}
(rp_gitea01) {
reverse_proxy http://gitea01.app.colo.1904.tech:80 {
header_down "X-Served-By" "Edge05"
}
}
(rp_adfs) {
reverse_proxy https://adfs.1904.tech:443 {
header_down "X-Served-By" "Edge05"
}
}
##### END OF REVERSE PROXY SNIPPETS #####
#### START OF TLS SNIPPETS #####
#Private CA issued, issued for wildcard externally-facing domains
(tls_ca_ext_wildcard) {
tls /etc/ssl/certs/BCT-Edge05-BCTPublicDomains-Wildcard.pem /etc/ssl/private/BCT-Edge05-BCTPublicDomains-Wildcard.key
}
#Private CA issued, issued for server's hostname
(tls_ca_int_wildcard) {
tls /etc/ssl/certs/edge05.dmz.colo.1904.tech.pem /etc/ssl/private/edge05.dmz.colo.1904.tech.key
}
#Cloudflare DNS API key for provisioning LE's DNS Challenge records
(tls_le_boldcity.tech) {
tls {
dns cloudflare {$CLOUDFLARE_API_KEY}
}
}
#Cloudflare issued Origin Certificate for use with Cloudflare proxy
(tls_cf_boldcity.tech) {
tls /etc/ssl/cf/boldcity.tech/cert.pem /etc/ssl/cf/boldcity.tech/priv.key
}
###### END OF TLS SNIPPETS #####
####### END OF ALL SNIPPETS #######
####### START OF SITE DECLARATIONS#######
#We want this domain to utilize the Cloudflare-issued TLS Certificate as the public endpoint is proxied
cloud.boldcity.tech drive.boldcity.tech {
import rp_nextcloud01
import tls_cf_boldcity.tech
redir /.well-known/carddav https://ingest.cloud.boldcity.tech/remote.php/dav/ 302
redir /.well-known/caldav https://ingest.cloud.boldcity.tech/remote.php/dav/ 302
# log / /var/log/caddy/cloud.boldcity.tech.log {combined}
}
#Use a Caddy-generated LE TLS certificate
ingest.cloud.boldcity.tech {
import rp_nextcloud01
import tls_le_boldcity.tech
}
#Use a Caddy-generated LE TLS certificate
git.boldcity.tech {
import rp_gitea01
import tls_le_boldcity.tech
}
#Use wildcard certificate from internal private CA
enterpriseregistration.potts.it {
import rp_adfs
import tls_ca_ext_wildcard
}
#Use wildcard certificate from internal private CA
enterpriseregistration.1904.tech {
import rp_adfs
import tls_ca_ext_wildcard
}
3. The problem I’m having:
I am attempting to replace my nginx-based reverse proxy in my lab with Caddy.
I have multiple different scenarios that necessitate the use of one of three different type of certificates for each particular FQDN that is being proxied:
- Caddy-managed Let’s Encrypt certificate, issued for the individual FQDN (
git.boldcity.tech
) - Cloudflare-issued origin CA certificate, issued for a wildcard of the base domain (
*.boldcity.tech
) - Internal private CA-issued certificate, usually issued for a wildcard of the base domain.
To increase scalability for myself, I am using snippets in a similar way to how I did things in nginx, as there will be multiple external domains that use the same backend server, each potentially using different certificate types.
(Yes, it’s a pain to keep organized and, among other reasons, I want to move to Caddy to eventually utilize the API to automate much of this…)
When I utilize the above Caddyfile, Caddy utilizes non-desired certificates for each endpoint, presumably because it’s doing things in the order it reads the config file and I am doing something wrong…
In this example, it seems to utilize:
- wildcard CF cert for the first site as desired
- for the second site it doesn’t encounter a cert that matches the secondary subdomain (which is accurate) and generates a LE cert
- It sees that it already has a cert that will work (wildcard CF cert) and uses it instead of a LE cert
- for the 4th and fifth it uses the correct internal CA.
Any additional sites I add use all sorts of non-desired certs as well, seemingly based on the order of their inclusion. The config file was trimmed down to exclude the 30+ other sites & 10 domains/CF Certs that are all redundant of what is shown.
I completely understand that I am utilizing this in a pretty unique implementation of an atypical scenario but I figure there has to be a way to convince Caddy to use a specific cert for a specific site, without having to resorting to putting the sites in the config file in a specific order, which seems pretty unsustainable.
What am I missing to make this work?
Thanks!