[SOLVED] Server POST request works with http but not with https ERROR: routines::packet length too long

Server POST request works with http but not with https ERROR: routines::packet length too long

I have a server which hosts a leaderboard to which I need a GET and a POST request. I can easily run

curl https://rancic.org/games/insta-kill/leaderboard.csv

to GET the leaderboard info. The server is also set up to receive POST requests, however it only works for http, not for https.

# This works fine
$ curl -X POST http://rancic.org:3434/leaderboard -d 'name,123,25,00:10'
# This doesn't work
$ curl -X POST https://rancic.org:3434/leaderboard -d 'name,123,25,00:10'
curl: (35) OpenSSL/3.2.0: error:0A0000C6:SSL routines::packet length too long

Note the only difference is http and https. My server has properly configured https connection, and opening the website with https://rancic.org works fine. I also ran a SSL Labs analysis and there weren't any issues. The result was this

# Protocols enabled
TLS 1.3 Yes
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3   No
SSL 2   No

I believe the error is on my server, something that needs be configured (perhaps it's the SSL? But I tried to curl it with --tlsv1.2 and it gave me the same error). It's also possible that there is a client problem, but I think this is less likely.

EDIT: This is the output I get with the verbose flag

Note: Unnecessary use of -X or --request, POST is already inferred.
* Host rancic.org:3434 was resolved.
* IPv6: (none)
* IPv4: 145.14.157.74
*   Trying 145.14.157.74:3434...
* Connected to rancic.org (145.14.157.74) port 3434
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS alert, record overflow (534):
* OpenSSL/3.2.0: error:0A0000C6:SSL routines::packet length too long
* Closing connection
curl: (35) OpenSSL/3.2.0: error:0A0000C6:SSL routines::packet length too long

Solution

You are using the same target port 3434 in the URL for both HTTP and HTTPS. While it would be in theory possible to create a server which supports both HTTP and HTTPS on the same port this is very very unusual and most servers don't support such configuration.

This means it is unlikely that the server has HTTPS enabled on the URL port you use. Still, the response from the server will be interpreted by the client as HTTPS even though its plain HTTP. This results in the strange error messages you get.

The fix is a) to properly implement HTTPS at the server and b) to use the right port for HTTPS in the client, which will be different from the HTTP port.