Local ssl broken out of the box

Help
1

1. The problem I’m having:

I’m trying to run a containerized service on 5000 and use caddy to provide self-signed ssl so that the service can be accessed via https.

To do so, I’m running this:

sudo -E caddy reverse-proxy --to :5000

I have confirmed that the underlying service is working properly and serving requests via:

curl -vL http://127.0.0.1:5000

However, curling caddy results in the error below

2. Error messages and/or full log output:

curl https://127.0.0.1 -vL  
*   Trying 127.0.0.1:443...
* Connected to 127.0.0.1 (127.0.0.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS alert, internal error (592):
* OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error
* Closing connection
curl: (35) OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error

caddy command output:

2024/05/20 23:01:09.775	WARN	admin	admin endpoint disabled
2024/05/20 23:01:09.775	INFO	http.auto_https	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "proxy", "https_port": 443}
2024/05/20 23:01:09.776	INFO	http.auto_https	enabling automatic HTTP->HTTPS redirects	{"server_name": "proxy"}
2024/05/20 23:01:09.776	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc00012a100"}
2024/05/20 23:01:09.796	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
2024/05/20 23:01:09.796	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2024/05/20 23:01:09.797	INFO	http.log	server running	{"name": "proxy", "protocols": ["h1", "h2", "h3"]}
2024/05/20 23:01:09.797	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2024/05/20 23:01:09.797	INFO	http	enabling automatic TLS certificate management	{"domains": ["localhost"]}
2024/05/20 23:01:09.797	WARN	tls	stapling OCSP	{"error": "no OCSP stapling for [localhost]: no OCSP server specified in certificate", "identifiers": ["localhost"]}
Caddy proxying https://localhost -> :5000
2024/05/20 23:01:09.801	WARN	tls	storage cleaning happened too recently; skipping for now	{"storage": "FileStorage:/root/.local/share/caddy", "instance": "a273df8a-2cec-42bc-9267-a85bb4ca4676", "try_again": "2024/05/21 23:01:09.801", "try_again_in": 86399.999999739}
2024/05/20 23:01:09.801	INFO	tls	finished cleaning storage units

3. Caddy version:

caddy --version
v2.7.6

4. How I installed and ran Caddy:

a. System environment:

Fedora:

caddy-2.7.6-2.fc40.x86_64

b. Command:

sudo -E caddy reverse-proxy --to :5000

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

N/A

5. Links to relevant resources:

2

Caddy proxying https://localhost -> :5000

Try https://localhost

1 Like
3

I can’t believe it was so simple. This worked, thank you:

curl https://localhost -vL

However, it’s still inaccessible over the lan, giving the same error as before:

 curl https://192.168.0.105 -vL
*   Trying 192.168.0.105:443...
* Connected to 192.168.0.105 (192.168.0.105) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS alert, internal error (592):
* OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error
* Closing connection
curl: (35) OpenSSL/3.2.1: error:0A000438:SSL routines::tlsv1 alert internal error

How can I resolve this? Do I need to manually download the root cert from the server and put it in the client’s trusted certs dir?

4

Also, the documentation uses 127.0.0.1 quite frequently. It would be good for this to be changed if it’s not the right thing to do:

edit: I see it’s 127.0.0.1 for the caddyfile, but localhost for quickstarting https with a command.

This is documented correctly, but a bit confusing for new users.

5

Right, because as the logs show, Caddy is serving https://localhost, not https://192.168.0.105. You can do --from https://192.168.0.105 to make Caddy proxy on that host instead, though.

1 Like
6

See, this is why I hesitate to add examples to the docs. People take them literally. And I don’t know how to teach people what to know about these.

It totally depends on the environment. Sometimes 127.0.0.1 is correct.

1 Like
7

perfect, thanks.

8

Totally valid. thanks again for your help.

1 Like
9

(Sorry for the curtness.) Anyway, welcome to using Caddy. :slight_smile:

2 Likes
10

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