TLS error when using Caddy in front of Adguard home

[ishan (Ishan Jain)]

1. The problem I’m having:

I have adguard home listening on port 8443. It is using TLS(It’s referring to the certificates/key generated by Caddy and I have also tested with certificates generated directly with certbot).

I am proxying <domain>:443/dns-query* traffic to adguard home instance but I keep getting “TLS: Internal errors” in the output of dig and DoH does not work.

2. Error messages and/or full log output:

➜  ~ dig +https @dns.ishan.pw google.com
;; Connection to 2401:c080:3400:2e43:5400:4ff:fe5a:5550#443(2401:c080:3400:2e43:5400:4ff:fe5a:5550) for google.com failed: TLS error.
;; Connection to 2401:c080:3400:2e43:5400:4ff:fe5a:5550#443(2401:c080:3400:2e43:5400:4ff:fe5a:5550) for google.com failed: TLS error.
;; Connection to 2401:c080:3400:2e43:5400:4ff:fe5a:5550#443(2401:c080:3400:2e43:5400:4ff:fe5a:5550) for google.com failed: TLS error.
;; Connection to 139.84.164.110#443(139.84.164.110) for google.com failed: TLS error.

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

a. System environment:

arch/x64

b. Command:

caddy run -c caddy.json

c. Service/unit/compose file:

    {
              "match": [
                {
                  "host": ["dns.ishan.pw"]
                }
              ],
              "handle": [
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "handle": [
                        {
                          "handler": "reverse_proxy",
                          "transport": {
                            "protocol": "http",
                            "tls": {
                              "server_name": "dns.ishan.pw"
                            }
                          },
                          "upstreams": [
                            {
                              "dial": "127.0.0.1:8443"
                            }
                          ]
                        }
                      ],
                      "match": [
                        {
                          "path": ["/dns-query*"]
                        }
                      ]
                    },
                    {
                      "handle": [
                        {
                          "handler": "headers",
                          "response": {
                            "deferred": true,
                            "delete": ["Server"]
                          }
                        },
                        {
                          "handler": "reverse_proxy",
                          "upstreams": [
                            {
                              "dial": "127.0.0.1:1030"
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ],
              "terminal": true
            },

d. My complete Caddy config:

PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.

Am I proxying this incorrectly ?

[francislavoie]

What’s in Caddy’s logs? Enable debug level logging to get detailed logs. It’s hard to say what’s going on. Try making the same request with curl -v instead.

[ishan (Ishan Jain)]

Hey, This was happening when I was testing DoH with dig. I found the root cause for it.

In my previous setup, I was using nginx.
I don’t fully understand how but nginx serves up a TLS certificate even if the request does not contain SNI extension in Client Hello.
Caddy returns an error if SNI is needed to route request and it’s not provided in the request. (I personally like Caddy’s approach here).

There is a tracking issue here, Add the TLS SNI +[no]tls-sni option to dig for DoT and DoH (#3896) · Issues · ISC Open Source Projects / BIND · GitLab for adding SNI in DoH/DoT requests made with dig.

Dig DoH output,

➜  ~ dig +https @dns.ishan.pw -p 443 +tls-ca +tls-hostname=dns.ishan.pw  google.com
;; Connection to 2a0a:6040:4050::#443(2a0a:6040:4050::) for google.com failed: TLS error.
;; Connection to 2a0a:6040:4050::#443(2a0a:6040:4050::) for google.com failed: TLS error.
;; Connection to 2a0a:6040:4050::#443(2a0a:6040:4050::) for google.com failed: TLS error.

[francislavoie]

That makes sense. You can fill SNI using the default_sni global option in Caddy if you like, to provide baseline support for clients not sending SNI.