Can't get reverse proxy to work: ERR_SSL_PROTOCOL_ERROR

[Wouter_Samaey]

1. Caddy version (caddy version):

2.4.5

2. How I run Caddy:

caddy.exe reverse-proxy --from https://*:41951 --to https://localhost:41951

a. System environment:

Windows 10

3. The problem I’m having:

I want to make a service that is bound to localhost:41951 accessible from the LAN, so not the public internet and WITHOUT a domain name as that would complicate things for the LAN clients.

It appears Caddy is willing to proxy, but the SSL connection is bad… maybe because I’m using an IP and not a domain name?

The browser keeps telling me:

The connection for this site is not secure192.168.0.56 sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

4. Error messages and/or full log output:

Log output seams normal.

>caddy.exe reverse-proxy --from https://*:41951 --to https://localhost:41951
2021/10/06 07:46:05.470 WARN    admin   admin endpoint disabled
2021/10/06 07:46:05.471 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "proxy"}
2021/10/06 07:46:05.471 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc00033a460"}
2021/10/06 07:46:05.494 INFO    pki.ca.local    root certificate is already trusted by system   {"path": "storage:pki/authorities/local/root.crt"}
2021/10/06 07:46:05.495 INFO    http    enabling automatic TLS certificate management   {"domains": ["*"]}
2021/10/06 07:46:05.496 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [*]: no OCSP server specified in certificate"}
2021/10/06 07:46:05.496 INFO    tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\wouter\\AppData\\Roaming\\Caddy"}
2021/10/06 07:46:05.497 INFO    autosaved config (load with --resume flag)      {"file": "C:\\Users\\wouter\\AppData\\Roaming\\Caddy\\autosave.json"}
Caddy proxying https://*:41951 -> https://localhost:41951
2021/10/06 07:46:05.499 INFO    tls     finished cleaning storage units

5. What I already tried:

I tried various notations in the --from section, but no luck. For example I tried:

--from *:41951
--from https://*:41951

None of these combinations work.

[matt (Matt Holt)]

Try removing the * from your address. That matches only a single domain label.

You might just be better off using the domain or IP there though, for cert reasons.

[Wouter_Samaey]

Hey @matt ,

I tried what you said, but now I get an error in the output:

2021/10/06 10:20:55.744 ERROR   http.log.error  remote error: tls: internal error       {"request": {"remote_addr": "192.168.0.56:59864", "proto": "HTTP/2.0", "method": "GET", "host": "192.168.0.56:41951", "uri": "/DYMO/DLS/Printing/StatusConnected", "headers": {"Sec-Fetch-User": ["?1"], "Cache-Control": ["max-age=0"], "Sec-Ch-Ua": ["\"Chromium\";v=\"94\", \"Microsoft Edge\";v=\"94\", \";Not A Brand\";v=\"99\""], "Sec-Ch-Ua-Platform": ["\"Windows\""], "Sec-Fetch-Site": ["none"], "Sec-Fetch-Mode": ["navigate"], "Accept-Encoding": ["gzip, deflate, br"], "Accept-Language": ["en-US,en;q=0.9,nl;q=0.8"], "Sec-Ch-Ua-Mobile": ["?0"], "Upgrade-Insecure-Requests": ["1"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36 Edg/94.0.992.38"], "Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"], "Sec-Fetch-Dest": ["document"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "h2", "proto_mutual": true, "server_name": ""}}, "duration": 0.0017749, "status": 502, "err_id": "7w1khvimh", "err_trace": "reverseproxy.statusError (reverseproxy.go:858)"}

Any ideas?

The service I’m proxying to uses a SSL cert that is valid. Only thing is it does not have a domein either. It just listens on 127.0.0.1.

This is the cert:

If I point my browser to the same URL but on the localhost, everything works fine, so the proxy is having an issue here.

[Wouter_Samaey]

@Wouter_Samaey

reverseproxy.statusError (reverseproxy.go:858)

Sounds like an error in this Go file?

[francislavoie]

This is because your upstream is probably not serving a certificate with localhost as the subject name and/or is not signed by a root that Caddy trusts.

Quick google for “DYMO” shows me this:

GitHub - njh/dymo-root-ca-security-risk: An analysis of the DYMO Root CA...

Apparently this is installed by a label printer?

[matt (Matt Holt)]

Nah, that’s just the line where the error value was created, not a problem in the code.

And I agree with Francis about the reason for the error.

[francislavoie]

Also noticed, the config doesn’t really seem to make sense – you can’t have two different processes bind to the same port number. I’m surprised that Caddy would have even started up when you already have something bound to port 41951 on the same machine

Anyways if you’re using this for LAN, and are comfortable ignoring trust issues (which is totally insecure, but if it’s just in your LAN and you’re aware of the risks, it’s ok), you probably should use a Caddyfile instead:

https://:41951 {
	reverse_proxy https://localhost:41951 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

reverse_proxy (Caddyfile directive) - Caddy Documentation

[Wouter_Samaey]

Yep, this seams to be the issue and the Dymo webservice is closed source, so I cannot fix or replace it.
Will need to do some serious thinking about this one.