1. Caddy version:
v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=
2. How I installed, and run Caddy:
My copy of caddy is being compiled with:
sudo xcaddy build --with github.com/gamalan/caddy-tlsredis \
--with github.com/caddy-dns/cloudflare \
--with github.com/mholt/caddy-ratelimit \
--with github.com/mholt/caddy-l4
I am currently running caddy with the supervision of pm2. Everything related to caddy is ran under an user named caddy
.
a. System environment:
Server machine is Raspberry Pi 4, Debian 11 (bullseye), aarch64 architecture.
b. Command:
/usr/bin/caddy run --environ --config /etc/caddy/Caddy.json
d. My complete Caddy config:
{
"logging": {
"logs": {
"default": {
"level": "DEBUG",
"writer": {
"filename": "/var/log/caddy/process.log",
"output": "file",
"roll_size_mb": 4769
},
"encoder": {
"format": "console",
"time_local": true
}
}
}
},
"storage": {
"Client": null,
"ClientLocker": null,
"Logger": null,
"address": "127.0.0.1:6379",
"aes_key": "",
"db": 1,
"host": "",
"key_prefix": "",
"module": "redis",
"password": "REDACTED",
"port": "",
"timeout": 0,
"tls_enabled": false,
"tls_insecure": false,
"username": "",
"value_prefix": ""
},
"apps": {
"http": {
"http_port": 80,
"https_port": 443,
"servers": {
"srv0": {
"listen": [":443"],
"routes": [{
"match": [{
"host": ["testdomain.org", "*.testdomain.org"]
}],
"handle": [{
"handler": "subroute",
"routes": [{
"handle": [{
"handler": "subroute",
"routes": [{
"handle": [{
"handler": "reverse_proxy",
"upstreams": [{
"dial": "172.25.69.101:6060"
}]
}]
}]
}],
"match": [{
"host": ["chord.testdomain.org"]
}]
}]
}],
"terminal": true
}],
"tls_connection_policies": [{
"match": {
"sni": ["testdomain.org"]
},
"client_authentication": {
"trusted_ca_certs": ["REDACTED"],
"mode": "require_and_verify"
}
}, {
"match": {
"sni": ["*.testdomain.org"]
},
"client_authentication": {
"trusted_ca_certs": ["REDACTED"],
"mode": "require_and_verify"
}
}, {}],
"strict_sni_host": true
}
}
},
"layer4": {
"servers": {
"mssql_DB": {
"listen": [":1433"],
"routes": [
{
"handle": [
{
"handler": "proxy",
"upstreams": [
{
"dial": ["172.25.69.101:15930"]
}
]
}
]
}
]
}
}
},
"tls": {
"automation": {
"policies": [{
"subjects": ["testdomain.org"]
},
{
"subjects": ["*.testdomain.org"],
"issuers": [{
"challenges": {
"dns": {
"provider": {
"api_token": "REDACTED",
"name": "cloudflare"
},
"resolvers": ["1.1.1.1"]
}
},
"module": "acme"
}, {
"challenges": {
"dns": {
"provider": {
"api_token": "REDACTED",
"name": "cloudflare"
},
"resolvers": ["1.1.1.1"]
}
},
"module": "zerossl"
}]
}]
}
}
}
}
3. The problem I’m having:
Hi there, first thing first. The db server (msSQL) mentioned later is hosted on secondary Raspi with TLS encryption via self-signed certificate.
The Caddy server is hosted on primary Raspi, my own self-signed CA is originated from here. My goal is to use Caddy to reverse proxy TCP connection to the db server. With the help of layer 4 module, it finally worked fine!!! Well only if user disables certificate verification on the client software.
Hence the problem is I am struggling to find a way to make the mssql_DB
caddy layer 4 server which listens on port 1433
to use previously obtained wildcard Let’s Encrypt certificate.
So, the request path looks like this:
Note: The user will connect to the server not through IP but via a domain name, which is home.testdomain.org
.
Client SQL Management Software → Caddy TCP home.testdomain.org:1433
— (reverse TCP) → local network msSQL server 15930
port .
I googled for quite some times and it seems like that, (correct me if i’m wrong) the general way of doing this is capturing all TLS through port 443
and then re-routes the request based the sni
or something else.
Sorry if my explanation is a bit off, is there any ways I can accomplish the goal of enabling Let’s Encrypt certificate on the home.testdomain.org:1433
mentioned above?
4. Error messages and/or full log output:
The caddy log file only produces those two lines when a client tries to connect to the msSQL server.
2023/01/25 02:28:04.132 DEBUG layer4.handlers.proxy dial upstream {"remote": "172.25.69.1:57076", "upstream": "172.25.69.101:15930"}
2023/01/25 02:28:04.184 DEBUG layer4 connection stats {"remote": "172.25.69.1:57076", "read": 285, "written": 1741, "duration": 0.052489367}
Screenshot below is the error while connecting to the msSQL server through caddy.
Note: Disabling SSL/TLS certificate verification on msSQL client will fix the issue.
5. What I already tried:
I have searched around my issue for quite some time already but I cannot find an exact match that’s related absolutely to this problem I’m facing.