Keep getting TLS Alert, internal error (592)

1. Output of caddy version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

2. How I run Caddy:

As a service on ubuntu via oracle’s free cloud tier implementation. It is run in conjunction with a Foundry server which broadcasts on port 30000. I am attempting to create a reverse proxy to redirect 80 to 443 (the default per Caddy’s documentation) and 443 to localhost:30000 (where the server I want to hit is)

a. System environment:

Ubuntu. Installed Caddy via the commands below.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf '' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf '' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

b. Command:

sudo service caddy start

c. Service/unit/compose file:

I don’t know what this is :frowning:

d. My complete Caddy config:

# This replaces the existing content in /etc/caddy/Caddyfile

    reverse_proxy localhost:30000
    encode zstd gzip

# Refer to the Caddy docs for more information:

3. The problem I’m having:

I am trying to establish a reverse proxy to forward all ports to localhost:30000 where a working server is located. (the server is working and works if I access it directly over http. When I attempt to access it I get a timeout error, when I use curl -v https://localhost I get TLS Alert, internal error (592) and it fails.

4. Error messages and/or full log output:

ubuntu@foundry:~$ curl -v https://localhost
*   Trying
* Connected to localhost ( port 443 (#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):
* TLSv1.2 (IN), TLS header, Unknown (21):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:0A000438:SSL routines::tlsv1 alert internal error
* Closing connection 0
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error

al certificate managers yielded no certificates and no errors","remote_ip":"","remote_port":"39710","sni":"localhost"}
Jan 16 04:31:32 foundry caddy[6018]: {"level":"debug","ts":1673843492.871479,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"","remote_port":"39710","server_name":"localhost","remote":"","identifier":"localhost","cipher_suites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"cert_cache_fill":0.0001,"load_if_necessary":true,"obtain_if_necessary":true,"on_demand":false}
Jan 16 04:31:32 foundry caddy[6018]: {"level":"debug","ts":1673843492.8715444,"logger":"http.stdlib","msg":"http: TLS handshake error from no certificate available for 'localhost'"}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.6222188,"logger":"events","msg":"event","name":"tls_get_certificate","id":"eaf0e1f4-f2ad-4aa0-9b2e-fb4bb58a6efd","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"ServerName":"localhost","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[772,771],"Conn":{}}}}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.622297,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"localhost"}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.6223054,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*"}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.6223097,"logger":"tls.handshake","msg":"all external certificate managers yielded no certificates and no errors","remote_ip":"","remote_port":"49954","sni":"localhost"}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.6223154,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"","remote_port":"49954","server_name":"localhost","remote":"","identifier":"localhost","cipher_suites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"cert_cache_fill":0.0001,"load_if_necessary":true,"obtain_if_necessary":true,"on_demand":false}
Jan 16 04:33:10 foundry caddy[6018]: {"level":"debug","ts":1673843590.6231406,"logger":"http.stdlib","msg":"http: TLS handshake error from no certificate available for 'localhost'"}

5. What I already tried:

Well I read the entire getting started documentation for Caddy and tried various methods including

caddy reverse-proxy --from --to localhost:30000

This also returned an identical error. I also attempted a full re-install of the package which didn’t help either. I also tried multiple different variations of the config based on what I was reading in the manuals and had the same error throughout.
I also tried with (an alternate domain I also own but was worried the subdomain was the issue hence the current config.)
I know I’m probably messing up something obvious and I feel bad asking for help but after putting in well over 4 hours I’m not sure what else to do :confused:
Thanks for any input! hopefully it’s an easy fix.

6. Links to relevant resources:

This is the guide I started out with Always Free Oracle Cloud Hosting Guide for Foundry | Foundry VTT Community Wiki from D30 on. All the things I tried were after that.

Well, you’ve told caddy to use the hostname “”, but you’re trying to access it via “localhost”. Caddy is unable to find a certificate to send for that. Does using curl with the full domain name work?


Make sure you’ve read Keep Caddy Running — Caddy Documentation to understand how to use Caddy as a systemd service.

If you’re running Caddy as a service, don’t run Caddy with the CLI commands like caddy run, caddy start, caddy reverse-proxy etc.

Doing so can mess up the Caddy instance running in systemd, because it might send a request to it via the admin API, or use the wrong user, storing your certs/keys in the wrong place.

That’s correct. The site address tells Caddy what certificate to try to issue. If a request comes in for a domain different than what Caddy has a certificate for, the TLS handshake will fail.

If you use localhost as the site address, Caddy will issue a cert using its internal CA (self-signed-ish). You might need to run sudo caddy trust to make it work for your browser.

I have now read this, thanks!

This is the error I get when trying to curl for the fqdn. When I try to curl from my personal machine and not the cloud box it doesn’t even get this far.

ubuntu@foundry:~$ curl -v
*   Trying
* connect to port 443 failed: Connection timed out
* Failed to connect to port 443 after 129243 ms: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to port 443 after 129243 ms: Connection timed out

My personal desktop

PS C:\Users\kschm> curl -v
VERBOSE: GET with 0-byte payload
curl : Unable to connect to the remote server
At line:1 char:1
+ curl -v
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

In regards to your statement about localhost I have run the sudo caddy trust command before, as part of my troubleshooting. This is what I get now.

sudo caddy trust
2023/01/16 14:11:44.607 INFO    root certificate is already trusted by system   {"path": "localhost:2019/pki/ca/local"}

So turns out I’m an idiot, my apologies for wasting everyone’s time here, I double checked the ingress rules and turns out I had put port 43 instead of 443 as the allowed port, so the Iptable was correct on the box but not on the cloud.

So I was getting a timeout error because the port was closed… :man_facepalming:

1 Like

No, not at all, that’s the point of the forums!

Glad you find the issue :blush:

1 Like