Error code: SSL_ERROR_RX_RECORD_TOO_LONG

norricorp · February 9, 2023, 12:06pm

1. Caddy version:

addy version
v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

2. How I installed, and run Caddy:

Installed Caddy on a mint 21 linux VM running on a windows PC.
Followed install docs for Ubuntu packages.
Caddy is running on startup.
Changed Caddyfile in /etc/caddy and run caddy reload.

a. System environment:

Mint 21, VM on windows PC host

b. Command:

Used caddy reload to reload new Caddyfile

caddy reload

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddy config:

# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace ":80" below with your
# domain name.

:8555 {
	reverse_proxy localhost:8055
}

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

3. The problem I’m having:

I am running directus on http://localhost:8055. I can access this both locally and from the host. The VM is set to share the host IP.
But if I try to access https://localhost:8555 on the VM or https://vm-name:8555 within firefox, I get
An error occurred during a connection to mint21-wolfsberg:8555. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the web site owners to inform them of this problem.

So I stopped the caddy server, and used
caddy reverse-proxy --from :8555 --to 8055
on the command line

Then run curl . Output below

4. Error messages and/or full log output:

$ curl -v 127.0.0.1:8055
*   Trying 127.0.0.1:8055...
* Connected to 127.0.0.1 (127.0.0.1) port 8055 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:8055
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Content-Security-Policy: script-src 'self' 'unsafe-eval';worker-src 'self' blob:;child-src 'self' blob:;img-src 'self' data: blob: https://cdn.directus.io;media-src 'self' https://cdn.directus.io;connect-src 'self' https://*;default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';object-src 'none';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
< X-Powered-By: Directus
< Vary: Origin, Accept
< Access-Control-Allow-Credentials: true
< Access-Control-Expose-Headers: Content-Range
< Location: ./admin
< Content-Type: text/plain; charset=utf-8
< Content-Length: 29
< Date: Thu, 09 Feb 2023 11:55:35 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
 Connection #0 to host localhost left intact
Found. Redirecting to ./adminj

And caddy log
$ caddy reverse-proxy --from :8555 --to 8055
2023/02/09 11:53:59.109	WARN	admin	admin endpoint disabled
2023/02/09 11:53:59.111	INFO	http.log	server running	{"name": "proxy", "protocols": ["h1", "h2", "h3"]}
Caddy proxying http://:8555 -> 8055:80
2023/02/09 11:53:59.112	INFO	tls	cleaning storage unit	{"description": "FileStorage:/home/jnorris/.local/share/caddy"}
2023/02/09 11:53:59.116	INFO	tls	finished cleaning storage units
2023/02/09 11:53:59.117	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc000140ee0"}

5. What I already tried:

So from looking at the caddy output, there was no reaction to curl. The log output occured when I started caddy.

But looking at curl, it did find directus. And redirected to directus/admin. Do I have to create a certificate? From the caddy docs, I thought it created a cert so I may be misunderstanding what is happening.

In summary, I want caddy to take an https address and pass that to a http address. Is directus rejecting this? Is this a dieectus problem?
Also the output in curl does not include the output within the browser regarding ssl record too long.

6. Links to relevant resources:

norricorp · February 9, 2023, 12:36pm

It seems I might require “tls internal” as part of the 8555 block in the caddyfile?
Have added that and identical result.
So perhaps not?

Whitestrake · February 10, 2023, 4:45am

So from looking at the caddy output, there was no reaction to curl. The log output occured when I started caddy.

That’s because your curl command was issued directly to the upstream service (port 8055) and not Caddy (port 8555), bypassing Caddy. As for the record length issue…

The reason you can’t connect to https://*:8555 is because Caddy is serving HTTP on this port. The “SSL record” is too long because Caddy simply isn’t responding with proper HTTPS.

Caddy can’t easily manage a certificate for a site for which the domain name is not known. You would require On-Demand TLS for that functionality.

See:
https://caddyserver.com/docs/automatic-https#on-demand-tls

Alternatively, if you set a hostname (e.g. caddy reverse-proxy --from localhost:8555 --to :8055), it should use internal TLS, and setting a full domain name should see it attempting to requisition a certificate from a public service.

Further, because your caddy reverse-proxy command didn’t have a colon(:) in front of the upstream port, it assumed (as you can see in the above quoted Caddy log detail) that 8055 is the hostname and then proxied to the default port 80 on that host. You’ll need to specify the full --to :8055 to ensure Caddy knows you’re talking about a port, here.

norricorp · February 10, 2023, 9:57am

Hi Matthew,
the only thing I can think of with curl 8055 is “D’oh”. Yes that was pretty dumb.
The caddyfile is now

:8555 {
	reverse_proxy localhost:8055
	tls internal
}

And curl now …

$ curl -v https://localhost:8555
*   Trying 127.0.0.1:8555...
* Connected to localhost (127.0.0.1) port 8555 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* (5454) (IN), , Unknown (72):
* error:0A00010B:SSL routines::wrong version number
* Closing connection 0
curl: (35) error:0A00010B:SSL routines::wrong version number

So I googled on “SSL routines::wrong version number” and there was a sugestion to use http://localhost:port. And …

$ curl -v http://localhost:8555
*   Trying 127.0.0.1:8555...
* Connected to localhost (127.0.0.1) port 8555 (#0)
> GET / HTTP/1.1
> Host: localhost:8555
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Access-Control-Allow-Credentials: true
< Access-Control-Expose-Headers: Content-Range
< Content-Length: 29
< Content-Security-Policy: script-src 'self' 'unsafe-eval';worker-src 'self' blob:;child-src 'self' blob:;img-src 'self' data: blob: https://cdn.directus.io;media-src 'self' https://cdn.directus.io;connect-src 'self' https://*;default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';object-src 'none';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 10 Feb 2023 09:32:41 GMT
< Location: ./admin
< Server: Caddy
< Vary: Origin, Accept
< X-Powered-By: Directus
< 
* Connection #0 to host localhost left intact
Found. Redirecting to ./admin

did “work”. The browser worked too - I got the directus page.

But this is not https.

Looking at the “Quick starts → reverse proxy” docs, it says that

caddy reverse-proxy --from :2080 --to :9000
curl -v 127.0.0.1:2080

will work. Then for https

caddy reverse-proxy --to :9000
curl -v https://localhost

and this will go to port 443. But I want 8555. So I tried
caddy reverse-proxy --from:8555 --to:8055 --internal-certs
and that started but again got the SSL routines: wrong version number. Though the log does say

2023/02/10 09:54:25.082	WARN	admin	admin endpoint disabled
2023/02/10 09:54:25.083	WARN	http	automatic HTTPS is completely disabled for server	{"server_name": "proxy"}

So in summary, it is safe to say I am confused.

norricorp · February 10, 2023, 10:58am

Just to add

github.com/curl/curl

curl: (35) error:0A00010B:SSL routines::wrong version number

opened 06:42AM - 17 Nov 22 UTC

closed 11:00PM - 18 Nov 22 UTC

Karthikdasari0423

HTTP/3

~~~ * Trying 127.0.0.1:8443... * Connect socket 5 over QUIC to 127.0.0.1:844…3 * Skipped certificate verification * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) * ALPN: offers http/1.1 * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * error:0A00010B:SSL routines::wrong version number * Connection #0 to host 127.0.0.1 left intact curl: (35) error:0A00010B:SSL routines::wrong version number ~~~ ### I did this curl -k -v --http3 https://127.0.0.1:8443/ ### I expected the following ~~~ * Trying 127.0.0.1:8443... * Connect socket 5 over QUIC to 127.0.0.1:8443 * Skipped certificate verification * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: https] * h2h3 [:authority: 127.0.0.1:8443] * h2h3 [user-agent: curl/7.86.1-DEV] * h2h3 [accept: */*] * Using HTTP/3 Stream ID: 0 (easy handle 0x55e3ba63bf40) > GET / HTTP/3 > Host: 127.0.0.1:8443 > user-agent: curl/7.86.1-DEV > accept: */* > * ngh3_stream_recv returns 0 bytes and EAGAIN < HTTP/3 200 < server: nginx/1.23.2 < date: Thu, 17 Nov 2022 06:40:56 GMT < content-type: text/html < content-length: 612 < last-modified: Tue, 21 Apr 2020 14:09:01 GMT < etag: "5e9efe7d-264" < alt-svc: h3=":8443"; ma=86400 < accept-ranges: bytes < <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> * Connection #0 to host 127.0.0.1 left intact ~~~ ### curl/libcurl version curl 7.87.0-DEV (x86_64-pc-linux-gnu) libcurl/7.87.0-DEV OpenSSL/3.0.0 zlib/1.2.11 ngtcp2/0.12.0-DEV nghttp3/0.8.0-DEV Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS HSTS HTTP3 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe TLS-SRP UnixSockets [curl -V output] ~~~ * Trying 127.0.0.1:8443... * Connect socket 5 over QUIC to 127.0.0.1:8443 * Skipped certificate verification * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) * Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) * ALPN: offers http/1.1 * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * error:0A00010B:SSL routines::wrong version number * Connection #0 to host 127.0.0.1 left intact curl: (35) error:0A00010B:SSL routines::wrong version number ~~~ ### operating system Ubuntu 20.04.5 LTS (GNU/Linux 5.4.0-131-generic x86_64)

suggests they may be an error in curl which has been fixed in a later version.

Of course, browser still fails with the SSL_ERROR_RX_RECORD_TOO_LONG too long

norricorp · February 10, 2023, 8:41pm

Any ideas on this?

francislavoie · February 10, 2023, 10:27pm

This is serving Caddy over HTTP, not HTTPS. So you cannot use https://localhost to connect to it.

Like @Whitestrake said, you must use a domain name if you want HTTPS.

norricorp · February 11, 2023, 9:04am

OK - so the domain name examples in the doc were not examples. I need a domain name. That really helps so many thanks.
No doubt I will hit more problems as I continue my caddy journey.

norricorp · February 13, 2023, 9:12am

And it’s working.
So I used vm-name:8555 { … }
Many thanks to @Whitestrake and @francislavoie for your help and patience.

system · March 15, 2023, 9:13am

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