Help getting basic website online via docker (continued...)

1. Caddy version (caddy version):

GitHub - caddyserver/caddy-docker: Source for the official Caddy v2 Docker Image (v2.0.0-rc.3)

2. How I run Caddy:


a. System environment:


b. Command:

docker run -d -p 32080:80 -p 32443:443 \
    --name caddy2 \
    -e "CADDYPATH=/etc/caddycerts" \
    -v $(pwd)/docker_data/caddy/Caddyfile:/etc/caddy/Caddyfile \
    -v $HOME/docker_data/caddy/ConvertMyThrow/:/etc/caddy/ConvertMyThrow/ \
    -v $HOME/docker_data/caddy/data/:/data \
    -v $HOME/docker_data/caddy/config/:/config \
    -v $HOME/docker_data/caddy/.caddy:/etc/caddycerts \

c. Service/unit/compose file:

see above

d. My complete Caddyfile or JSON config:


root * /etc/caddy/mySite/
try_files {path} /index.html

3. The problem I’m having:

Please see Help getting basic website online via docker, as I was working with @francislavoie and I let that get too stale so it was closed.

4. Error messages and/or full log output:

when navigating to localhost:32443 I get:

Secure Connection Failed
An error occurred during a connection to localhost:32443. Peer reports it experienced an internal error

and when navigating to localhost:32080 I get:

The connection was reset
The connection to the server was reset while the page was loading

The docker logs:

{"level":"info","ts":1591034243.5008187,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1591034243.5019696,"logger":"admin","msg":"admin endpoint started","address":"tcp/","enforce_origin":false,"origins":["localhost:2019","[::1]:2019",""]}
{"level":"info","ts":1591034243.5020933,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1591034243.5021677,"logger":"tls","msg":"cleaned up storage units"}
2020/06/01 17:57:23 [INFO][cache:0xc0005c3a90] Started certificate maintenance routine
{"level":"info","ts":1591034243.504031,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1591034243.5040474,"msg":"serving initial configuration"}
2020/06/01 17:58:26 http: TLS handshake error from no certificate available for ''
2020/06/01 17:58:26 http: TLS handshake error from no certificate available for ''
2020/06/01 18:06:35 http: TLS handshake error from no certificate available for ''
2020/06/01 18:06:35 http: TLS handshake error from no certificate available for ''

5. What I already tried:

see my prior forum post Help getting basic website online via docker

I finally managed to spin up a new ubuntu Mate VM. @francislavoie told me there was a DNS issue with the prior VM. This is a BRAND NEW VM. Only Docker has been installed, and nothing else has been done except for installing a couple other containers.

6. Links to relevant resources:

This just means that Caddy doesn’t have a certificate to offer up for It also means that the client is not sending ServerName (SNI) in the TLS handshake.

You have to either tell Caddy to manage a cert for or use a hostname instead.

Also, please upgrade to v2.0.0. :slight_smile:

Run docker pull caddy and use caddy instead of caddy/caddy in your docker commands to get the latest version.

1 Like

@francislavoie all set. I’ve switched the image for my container. Unfortunately still having the same issues.

@matt I’m not sure you’ve told me enough for me to be able to resolve this. I have no idea what needs to be done. I thought caddy managed the certificates? I thought that was the whole point? I get a similar error when I try to connect via a browser installed on the localhost.

2020/06/01 20:49:47 http: TLS handshake error from no certificate available for 'localhost'`

I’m not well versed in certificate management, which is the primary reason I wanted to try caddy to serve my website in https. Also, I’m just using whatever version is pulled from docker. I have watchtower installed to auto-update my containers. However, RC3 must still be the current one, as doing the new pull command resulted in me still having 2.0.0-rc.3

The latest is most definitely 2.0.0. See Docker Hub

1 Like

Of course it does, but it’s not magic either :slight_smile: It can’t read your mind – you have to tell it which domains it is authorized to manage certificates for. The docs will explain everything you need to know: Automatic HTTPS — Caddy Documentation – and my suggestion above is the minimal you need to do to enable automatic HTTPS.

docker pull caddy

by default will pull the latest. I had to run docker pull caddy:2.0.0 to explicitly get 2.0.0

@matt I’m unclear. I have the following line in my caddyfile:


The documentation says this is valid. Shouldn’t this cause caddy to simply manage certificates for all https traffic, locally, internally, and externally? I really don’t understand what you are even saying I am missing.

Correct! That is a valid site address, but it doesn’t tell Caddy anything about which hostnames it should manage certificates for.

The linked docs say:

Caddy implicitly activates automatic HTTPS when it knows a domain name (i.e. hostname) it is serving. Depending on how you run or configure Caddy, there are various ways to tell Caddy which domain names to use:

And a little later in the page it says:

All hostnames (domain names and IP addresses) qualify for fully-managed certificates if they:

  • are non-empty

Plus, our HTTPS quick start shows you a Caddyfile that will enable auto-HTTPS.

So, simply replacing :443 with (where is your domain name) is all you need to do.

ok, so making some progress. I replaced :443 with: 192.168.1.*, 172.17.0.*, localhost

This is working on the localhost. 2 issues now:

  1. When connecting on localhost, I needed to make an in-browser security exception when connecting to the site
  2. I am unable to connect from any other devices/browsers in my network. My local network is all on subnet 192.168.1.*, and my Docker network is 172.17.0.*, however I get browser error saying:

This site can’t provide a secure connection

And the docker logs show things like:

2020/06/01 22:30:16 http: TLS handshake error from no certificate available for '',

What are the final pieces of the puzzle that I am missing?

Still missing these final two pieces, if anybody can assist. I still haven’t figured out the hostname(s) I need to add to my caddyfile in order to make the site available on my internal network, only on the localhost. And on the localhost, I get the following in Firefox when connecting to the site:

Yes - you’re running Caddy in Docker. When it installs its local-only certificate authority, it does so… inside the Docker container. The actual Docker host (presumably where you’re running your browser) still won’t trust Caddy.

Quirk of interaction between Docker NAT, and SNI (or specifically the lack thereof).

Browsers don’t send SNI for IP addresses, so Caddy infers the server name from the IP address the client is connecting to (i.e. its own IP address). You might be connecting to a 192.168 address but the packets are being redirected to the 172.17 address, which explains why you’re seeing no certificate available for ''.

Caddy doesn’t appear to issue internal certificates for wildcarded IP addresses, not even with TLS on demand, which is why 172.17.0.* doesn’t work as a site label for this purpose.

The best way to fix this is to point an actual domain name at your Caddy server and add that domain name as a site address in your Caddyfile. That will ensure that Caddy knows exactly which certificate it needs, and browsers will send SNI to indicate this to Caddy so that it can select the appropriate HTTPS certificate.

1 Like

You can look in your $HOME/docker_data/caddy/data directory and you should find the root cert (pki directory) and you can install that manually to any trust stores you need it in.

1 Like

this can be closed. I finally added my domain to my caddyfile (I wasn’t ready yet to migrate from my production environment to caddy). However, everything is looking good. The site works locally and publicly. Thanks so much for the help!

1 Like

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