Https with self-signed fails with docker-compose

1. Caddy version (caddy version):

caddy:2.2.0-alpine

a. System environment:

Linux 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

b. Command:

docker-compose up

c. Service/unit/compose file:

version: "3.3"
services:
  proxy:
    image: caddy:2.2.0-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile
      - ./caddy-data:/data
      - ./caddy/caddy_config:/config
      - ./caddy/self_signed_certs:/etc/caddy/self_signed_certs

d. My complete Caddyfile or JSON config:

{
    auto_https disable_redirects
}

127.0.0.1:80 {
    respond "Hello, world!"
}

127.0.0.1:443 {
    tls /etc/caddy/self_signed_certs/cert.crt /etc/caddy/self_signed_certs/cert.key
    respond "Hello, world!"
}

3. The problem I’m having:

When running locally (from the host running docker)

curl -v --insecure https://127.0.0.1

The request fails with

*   Trying 127.0.0.1:443...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

If I use http curl -v http://127.0.0.1 it works as expected.

Also If I jump into the container and run the same curl curl -v --insecure https://127.0.0.1 it works as expected (answers Hello World)

Let me know if there is anymore information I can provide. Really I am unsure why the https fails via the docker host and works inside.

Hi Ronni, welcome –

What’s in Caddy’s logs when you try to connect over HTTPS?

Thanks @matt

Nothing is output in the logs when I try to connect via. https. is there anything I need to add to the config, as I understand it should output errors by default?

However if I inside the container run tcpdump I can see the incoming traffic. I attached the output in the bottom of this post.

I have also pushed the files to reproduce to a github repo at

https://github.com/RonniSkansing/caddy2-compose for anyone wanting to reproduce it should be as simple as clone and docker-compose up

tcpdump from inside container

08:21:58.057844 IP 172.28.0.1.52304 > 0588b2e702b4.443: Flags [S], seq 2980725664, win 64240, options [mss 1460,sackOK,TS val 1053687953 ecr 0,nop,wscale 7], length 0
08:21:58.057866 IP 0588b2e702b4.443 > 172.28.0.1.52304: Flags [S.], seq 3395407381, ack 2980725665, win 65160, options [mss 1460,sackOK,TS val 1764848651 ecr 1053687953,nop,wscale 7], length 0
08:21:58.057883 IP 172.28.0.1.52304 > 0588b2e702b4.443: Flags [.], ack 1, win 502, options [nop,nop,TS val 1053687953 ecr 1764848651], length 0
08:21:58.064803 IP 172.28.0.1.52304 > 0588b2e702b4.443: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1053687960 ecr 1764848651], length 517
08:21:58.064822 IP 0588b2e702b4.443 > 172.28.0.1.52304: Flags [.], ack 518, win 506, options [nop,nop,TS val 1764848658 ecr 1053687960], length 0
08:21:58.065102 IP 0588b2e702b4.443 > 172.28.0.1.52304: Flags [P.], seq 1:8, ack 518, win 506, options [nop,nop,TS val 1764848658 ecr 1053687960], length 7
08:21:58.065131 IP 172.28.0.1.52304 > 0588b2e702b4.443: Flags [.], ack 8, win 502, options [nop,nop,TS val 1053687960 ecr 1764848658], length 0
08:21:58.065173 IP 0588b2e702b4.443 > 172.28.0.1.52304: Flags [F.], seq 8, ack 518, win 506, options [nop,nop,TS val 1764848658 ecr 1053687960], length 0
08:21:58.066181 IP 172.28.0.1.52304 > 0588b2e702b4.443: Flags [F.], seq 518, ack 9, win 502, options [nop,nop,TS val 1053687961 ecr 1764848658], length 0
08:21:58.066197 IP 0588b2e702b4.443 > 172.28.0.1.52304: Flags [.], ack 519, win 506, options [nop,nop,TS val 1764848659 ecr 1053687961], length 0

Oh, I can’t remember if a certain recent change is in that version or an upcoming tag, but can you enable debug in your global options at the top of your Caddyfile? That might make the logs I’m looking for appear.

I enabled debug. Which yields this line

{"level":"debug","ts":1602269886.0510063,"logger":"http.stdlib","msg":"http: TLS handshake error from 172.31.0.1:46744: no certificate available for '172.31.0.2'"}

The autosave.json contains

{"apps":{"http":{"servers":{"srv0":{"listen":[":80"],"routes":[{"handle":[{"handler":"subroute","routes":[{"handle":[{"body":"Hello, world!","handler":"static_response"}]}]}],"match":[{"host":["127.0.0.1"]}],"terminal":true}]},"srv1":{"listen":[":443"],"routes":[{"handle":[{"handler":"subroute","routes":[{"handle":[{"body":"Hello, world!","handler":"static_response"}]}]}],"match":[{"host":["127.0.0.1"]}],"terminal":true}],"tls_connection_policies":[{"certificate_selection":{"any_tag":["cert0"]},"match":{"sni":["127.0.0.1"]}},{}]}}},"tls":{"certificates":{"load_files":[{"certificate":"/etc/caddy/self_signed_certs/cert.crt","key":"/etc/caddy/self_signed_certs/cert.key","tags":["cert0"]}]}}},"logging":{"logs":{"default":{"level":"DEBUG"}}}}

Okay, great. So this just means that the client is trying to make a TLS connection to 172.31.0.2 but Caddy is not configured with any certificates for that IP address.

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