TLS handshake error...first record does not look like a TLS handshake

1. Output of caddy version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

2. How I run Caddy:

On a dedicated Linux VM
As a gate from internet to 3 servers (4 services), with reverse proxy
Also a filter on some countries with caddy-maxmind-geolocation

a. System environment:

ubuntu 20.04
systemd

b. Command:

sudo systemctl enable --now caddy

 sudo caddy run


c. Service/unit/compose file:

# caddy.service
#
# For using Caddy with a config file.
#
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
#
# See https://caddyserver.com/docs/install for instructions.
#
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateDevices=yes
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddy config:

# Caddyfile
{
        debug
}

crios.bris.fr:6690 {
        reverse_proxy http://192.168.9.201:6690
}

3. The problem I’m having:

the service on the back-end did not work

Question: how to get the port in input of Caddy, in that case 6690?
I didn’t find it in the log.

4. Error messages and/or full log output:

TLS handshake error from 192.168.9.1:63373: tls: first record does not look like a TLS handshake

5. What I already tried:

remove http to use https:

reverse_proxy 192.168.9.201:6690

6. Links to relevant resources:

reverse_proxy defaults to HTTP, not HTTPS. Adding or removing http:// doesn’t do anything, since that’s already the default.

I don’t understand the question. What doesn’t work, exactly? Just saying “did not work” doesn’t give us any clues.

That looks like you’re making an HTTP request to an HTTPS server.

1 Like

Sorry, I was not clear enough. I did it like this also with the same result
reverse_proxy https://192.168.9.201:6690

I don’t understand the question. What doesn’t work, exactly? Just saying “did not work” doesn’t give us any clues.

what I’d like is
Win Synology Drive 6690 → router → caddy → Synology 6690
and it doesn’t work as Synology is expected 6690

That looks like you’re making an HTTP request to an HTTPS server.

I’ve tried both with the same result

tls: first record does not look like a TLS handshake means you are connecting with TLS to a non-TLS peer (probably HTTP or some other protocol).

Please post the full logs, we’re only guessing with just that error message in isolation.

sure:

1/ with (http):

# Caddyfile
{
        debug
}

crios.bris.fr:6690 {
        reverse_proxy http://192.168.9.201:6690
}
sudo caddy run
2023/01/05 12:48:36.973 INFO    using adjacent Caddyfile
2023/01/05 12:48:36.985 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/01/05 12:48:36.989 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/01/05 12:48:36.997 INFO    http    enabling HTTP/3 listener        {"addr": ":6690"}
2023/01/05 12:48:37.003 DEBUG   http    starting server loop    {"address": "[::]:6690", "tls": true, "http3": true}
2023/01/05 12:48:37.008 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/01/05 12:48:37.014 DEBUG   http    starting server loop    {"address": "[::]:80", "tls": false, "http3": false}
2023/01/05 12:48:37.018 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/01/05 12:48:37.023 INFO    http    enabling automatic TLS certificate management   {"domains": ["crios.bris.fr"]}
2023/01/05 12:48:36.993 INFO    tls.cache.maintenance   started background certificate maintenance  {"cache": "0xc000189340"}
2023/01/05 12:48:36.998 INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
2023/01/05 12:48:37.052 DEBUG   tls     loading managed certificate     {"domain": "crios.bris.fr", "expiration": "2023/03/12 16:44:05.000", "issuer_key": "acme-v02.api.letsencrypt.org-directory", "storage": "FileStorage:/root/.local/share/caddy"}
2023/01/05 12:48:37.148 INFO    tls     finished cleaning storage units
2023/01/05 12:48:37.275 DEBUG   tls.cache       added certificate to cache      {"subjects": ["crios.bris.fr"], "expiration": "2023/03/12 16:44:05.000", "managed": true, "issuer_key": "acme-v02.api.letsencrypt.org-directory", "hash": "a780dad0e16f4f95c1fa39d995aa6815e48cf68550b85e7243a08e3ad7293889", "cache_size": 1, "cache_capacity": 10000}
2023/01/05 12:48:37.282 DEBUG   events  event   {"name": "cached_managed_cert", "id": "f7f8f1ca-339e-4aac-8a69-338e4d8683a1", "origin": "tls", "data": {"sans":["crios.bris.fr"]}}
2023/01/05 12:48:37.291 INFO    autosaved config (load with --resume flag)      {"file": "/root/.config/caddy/autosave.json"}
2023/01/05 12:48:37.296 INFO    serving initial configuration
2023/01/05 12:49:13.193 DEBUG   http.stdlib     http: TLS handshake error from 192.168.9.1:54385: tls: first record does not look like a TLS handshake

2/ with (https):

{
        debug
}

crios.bris.fr:6690 {
        reverse_proxy https://192.168.9.201:6690
}
sudo caddy run
2023/01/05 12:51:25.423 INFO    using adjacent Caddyfile
2023/01/05 12:51:25.450 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/01/05 12:51:25.454 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/01/05 12:51:25.462 INFO    tls.cache.maintenance   started background certificate maintenance  {"cache": "0xc00036d340"}
2023/01/05 12:51:25.465 DEBUG   http    starting server loop    {"address": "[::]:80", "tls": false, "http3": false}
2023/01/05 12:51:25.468 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/01/05 12:51:25.471 INFO    http    enabling HTTP/3 listener        {"addr": ":6690"}
2023/01/05 12:51:25.475 DEBUG   http    starting server loop    {"address": "[::]:6690", "tls": true, "http3": true}
2023/01/05 12:51:25.478 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/01/05 12:51:25.485 INFO    http    enabling automatic TLS certificate management   {"domains": ["crios.bris.fr"]}
2023/01/05 12:51:25.496 DEBUG   tls     loading managed certificate     {"domain": "crios.bris.fr", "expiration": "2023/03/12 16:44:05.000", "issuer_key": "acme-v02.api.letsencrypt.org-directory", "storage": "FileStorage:/root/.local/share/caddy"}
2023/01/05 12:51:25.505 DEBUG   tls.cache       added certificate to cache      {"subjects": ["crios.bris.fr"], "expiration": "2023/03/12 16:44:05.000", "managed": true, "issuer_key": "acme-v02.api.letsencrypt.org-directory", "hash": "a780dad0e16f4f95c1fa39d995aa6815e48cf68550b85e7243a08e3ad7293889", "cache_size": 1, "cache_capacity": 10000}
2023/01/05 12:51:25.509 DEBUG   events  event   {"name": "cached_managed_cert", "id": "1e2bc15e-a2d4-446e-9fc6-e6fb992b3396", "origin": "tls", "data": {"sans":["crios.bris.fr"]}}
2023/01/05 12:51:25.483 INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
2023/01/05 12:51:25.530 INFO    autosaved config (load with --resume flag)      {"file": "/root/.config/caddy/autosave.json"}
2023/01/05 12:51:25.533 INFO    serving initial configuration
2023/01/05 12:51:25.540 INFO    tls     finished cleaning storage units
2023/01/05 12:51:31.472 DEBUG   http.stdlib     http: TLS handshake error from 192.168.9.1:54534: tls: first record does not look like a TLS handshake

Thanks for your reply!

I have to say that the Synology support has just answered that this service is not working with a reverse proxy, but should work directly:

After consulting with our specialists, I confirm that a reverse proxy rule would be applicable for Synology Drive web interface operation (or Synology Drive for Android), but it does not work for Synology Drive client synchronization (port 6690).

Even though I don’t understand why, so perhaps you should not spend too much time…

Regards
Pascal

PS: perhaps you know Win and Andoid sync open source software that work well with Caddy reverse-proxy and basic_auth…

To be clear, the problem is not with reverse_proxy, the problem is that your client (app/browser/whatever) is making HTTP requests when Caddy is expecting HTTPS requests.

Caddy is not even reaching the point of running the reverse_proxy handler because the connection failed at the TLS handshake before it could start handling the request.

Why are you using that port number? If you intended to use HTTPS for incoming traffic, why not omit the port number in your site address to use port 443, the default HTTPS port?

If you intended to accept HTTP traffic from your app/browser/client then prefix the site address with http:// to disable HTTPS (but obviously that turns off encryption and any device in between the client and server can see or manipulate the traffic if they wanted to).

Why are you using that port number? If you intended to use HTTPS for incoming traffic, why not omit the port number in your site address to use port 443, the default HTTPS port?

I don’t have the choice of the port in Synology app

image

If you intended to accept HTTP traffic from your app/browser/client then prefix the site address with http:// to disable HTTPS (but obviously that turns off encryption and any device in between the client and server can see or manipulate the traffic if they wanted to).

If I understand that’s between the client (the app on the PC) and caddy. I only could uncheck SSL


And it’s the same result

I think I’m going to change to other tools…

Thanks for the explanation!

This topic was automatically closed after 30 days. New replies are no longer allowed.