V2: no SSL or at least connection to private domain

1. My Caddy version (caddy version):


2. How I run Caddy:

a. System environment:

Docker container in Portainer on QNAP NAS

b. Command:

caddy file-server --domain cszr.dev

c. Service/unit/compose file:

docker run -d -p 80:80 -p 443:443 \
    -v /share/Valhalla/config/caddy/site/index.html:/usr/share/caddy/index.html \
    -v /share/Valhalla/config/caddy/data:/data \
    -v /share/Valhalla/config/caddy:/config \
    -v /share/Valhalla/config/caddy/caddyfile/Caddyfile:/etc/caddy/Caddyfile \
    caddy/caddy:latest caddy file-server --domain cszr.dev

d. My complete Caddyfile or JSON config:

	storage file_system {
		root	/etc/caddy

cszr.dev {
root * /share/Valhalla/config/caddy/site
try_files {path}.html {path}
encode gzip zstd brotli

www.cszr.dev {
	redir https://cszr.dev

3. The problem I’m having:

I am trying (for now) to set up SSL on the domain with Caddy, after which I will redirect my various containers to it (i.e. Sonarr to cszr.dev/sonarr).

4. Error messages and/or full log output:

2020/03/21 00:31:06.365	WARN	admin	admin endpoint disabled,
2020/03/21 00:31:06.365	INFO	http	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "static", "https_port": 443},
2020/03/21 00:31:06.365	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "static"},
2020/03/21 00:31:06 [INFO][cache:0xc0006bc640] Started certificate maintenance routine,
2020/03/21 00:31:06.365	INFO	tls	cleaned up storage units,
2020/03/21 00:31:06.366	INFO	http	enabling automatic TLS certificate management	{"domains": ["cszr.dev"]},
2020/03/21 00:31:06.366	INFO	autosaved config	{"file": "/config/caddy/autosave.json"},
2020/03/21 00:31:06 Caddy 2 serving static files on :443,
2020/03/21 00:31:06 [INFO][cszr.dev] Obtain certificate; acquiring lock...,
2020/03/21 00:31:06 [INFO][cszr.dev] Obtain: Lock acquired; proceeding...,
2020/03/21 00:31:07 [INFO] [cszr.dev] acme: Obtaining bundled SAN certificate given a CSR,
2020/03/21 00:31:07 [INFO][cszr.dev] Waiting on rate limiter...,
2020/03/21 00:31:07 [INFO][cszr.dev] Done waiting,
2020/03/21 00:31:08 [INFO] [cszr.dev] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3474197488,
2020/03/21 00:31:08 [INFO] [cszr.dev] acme: use tls-alpn-01 solver,
2020/03/21 00:31:08 [INFO] [cszr.dev] acme: Trying to solve TLS-ALPN-01,
2020/03/21 00:31:09 http: TLS handshake error from EOF,
2020/03/21 00:31:28 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3474197488,
2020/03/21 00:31:28 [ERROR] acme: Error -> One or more domains had a problem:,
[cszr.dev] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem), url: ,
 (challenge=tls-alpn-01 remaining=[http-01]),
2020/03/21 00:31:28 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3474197488,
2020/03/21 00:31:30 [INFO] [cszr.dev] acme: Obtaining bundled SAN certificate given a CSR,
2020/03/21 00:31:31 [INFO] [cszr.dev] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3474202221,
2020/03/21 00:31:31 [INFO] [cszr.dev] acme: Could not find solver for: tls-alpn-01,
2020/03/21 00:31:31 [INFO] [cszr.dev] acme: use http-01 solver,
2020/03/21 00:31:31 [INFO] [cszr.dev] acme: Trying to solve HTTP-01,
2020/03/21 00:31:31 [INFO][cszr.dev] Served key authentication (HTTP challenge)

5. What I already tried:

I am pretty sure my issue is the Caddyfile, I have tried various examples and it simply doesn’t work in any way. Furthermore, I have no idea if I have to recreate the Docker each time I change the Caddyfile or not. I’ve tried simply restarting, recreating, deleting all folders and recreating and nothing, still. The file is giving me a headache.

6. Links to relevant resources:

This is where I got most of my information, plus some StackOverflow articles and some from here, as well.

There’s your issue.

Omit the command for the container. What’s happening is that you’re telling Caddy to just run a file server on your domain, and to skip loading the Caddyfile.

/cc @hairyhenderson this might be a slight failure of the docker README, maybe we should clarify this part in the usage.

In Caddy v1, you could send SIGUSR2 to the process to make it trigger a graceful reload. I don’t think the signal is supported in v2, but v2 does support graceful reloads via the caddy reload command.

I haven’t tried this yet, but I think if you can just docker exec your running container and run caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile. I’m not certain about this, but I’d recommend giving it a shot. You can check the docker logs to see if this had any effect.

/cc @hairyhenderson we should add that caddy reload example to the README as well if that works.

I recommend setting up subdomains like sonarr.cszr.dev instead of trying to run your services under various paths. Caddy will fetch a certificate for each of those subdomains. Much easier.

Running services under subpaths can become very tricky depending on how the application handles relative asset paths (js/css files) in their HTML, and page links, etc.

You’ll need to be using the path inside the docker container here, that’s the path on your host system if I’m reading correctly. Your docker volume should look like:

-v /share/Valhalla/config/caddy/site:/usr/share/caddy

Then your root directive would be:

root * /usr/share/caddy

See the default Caddyfile that ships with the Docker image: https://github.com/caddyserver/dist/blob/master/config/Caddyfile

I would probably recommend against using brotli. See the note in the docs about the poor performance: https://caddyserver.com/docs/caddyfile/directives/encode

1 Like

Sorry for the long time for me to reply, I’ve only had the chance just now.
I did the following based on your feedback:

  • stopped the container, deleted all the files in the /config folder, the container, and the image itself;
  • recreated the container with the following command:
docker create \
    --name=Caddy \
    -p 80:80 \
    -p 443:443 \
    -v /share/Valhalla/config/caddy/site/index.html:/usr/share/caddy/index.html \
    -v /share/Valhalla/config/caddy/data:/data \
    -v /share/Valhalla/config/caddy:/config \
    -v /share/Valhalla/config/caddy/caddyfile/Caddyfile:/etc/caddy/Caddyfile \
    --restart unless-stopped \
  • changed the Caddyfile to the following, simpler one:

root * /usr/share/caddy
  • this is the log after starting the container:
 {"level":"info","ts":1585386861.1906657,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"},
{"level":"info","ts":1585386861.194969,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["localhost:2019"]},
{"level":"info","ts":1585386861.1953259,"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":1585386861.1953704,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"},
2020/03/28 09:14:21 [INFO][cache:0xc0006234a0] Started certificate maintenance routine,
{"level":"info","ts":1585386861.1957412,"logger":"tls","msg":"cleaned up storage units"},
{"level":"info","ts":1585386861.1959834,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["cszr.dev"]},
{"level":"info","ts":1585386861.196287,"msg":"autosaved config","file":"/config/caddy/autosave.json"},
{"level":"info","ts":1585386861.1963117,"msg":"serving initial configuration"},
2020/03/28 09:14:21 [INFO][cszr.dev] Obtain certificate; acquiring lock...,
2020/03/28 09:14:21 [INFO][cszr.dev] Obtain: Lock acquired; proceeding...,
2020/03/28 09:14:36 [ERROR] Making new ACME client: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get "https://acme-v02.api.letsencrypt.org/directory": net/http: TLS handshake timeout (attempt 1/2),
2020/03/28 09:14:46 [INFO][cszr.dev] Waiting on rate limiter...,
2020/03/28 09:14:46 [INFO][cszr.dev] Done waiting,
2020/03/28 09:14:46 [INFO] [cszr.dev] acme: Obtaining bundled SAN certificate given a CSR,
2020/03/28 09:14:47 [INFO] [cszr.dev] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3611629615,
2020/03/28 09:14:47 [INFO] [cszr.dev] acme: Could not find solver for: tls-alpn-01,
2020/03/28 09:14:47 [INFO] [cszr.dev] acme: use http-01 solver,
2020/03/28 09:14:47 [INFO] [cszr.dev] acme: Trying to solve HTTP-01,
2020/03/28 09:14:47 [INFO][cszr.dev] Served key authentication (HTTP challenge),
2020/03/28 09:14:47 [INFO][cszr.dev] Served key authentication (HTTP challenge),
2020/03/28 09:14:48 [INFO][cszr.dev] Served key authentication (HTTP challenge),
2020/03/28 09:14:48 [INFO][cszr.dev] Served key authentication (HTTP challenge),
2020/03/28 09:14:54 [INFO] [cszr.dev] The server validated our request,
2020/03/28 09:14:54 [INFO] [cszr.dev] acme: Validations succeeded; requesting certificates,
2020/03/28 09:14:55 [INFO] [cszr.dev] Server responded with a certificate.,
2020/03/28 09:14:56 [INFO][cszr.dev] Certificate obtained successfully,
2020/03/28 09:14:56 [INFO][cszr.dev] Obtain: Releasing lock,
  • as for this command you told me to run: --config /etc/caddy/Caddyfile --adapter caddyfile, it’s already in the container without me having to run it again

  • I have an index.html with a ‘hello world’ set up but not even that is showing when going to the URL, the site refuses the connection…

  • also, here is the website report: don’t know if this helps or not

This volume is odd. I think you might want to do -v /share/Valhalla/config/caddy/config:/config instead, because I think your volumes conflict with eachother. Not sure if this would matter in practice.

You can just make this -v /share/Valhalla/config/caddy/site:/usr/share/caddy instead of specifying index.html

Anyways, at this point this seems like a firewall/networking issue. If you’re not seeing a request in your logs, then either your hosting service doesn’t have the port open, or something on your host machine has the ports blocked.

What’s strange though is that it seems like Let’s Encrypt was able to connect over HTTP to get you a certificate.

What version of Caddy are you running? You can check with docker exec Caddy caddy --version (because you --name’d your container Caddy). You might want to docker pull the latest version, might fix things.


Thank you so much for your help! Apparently I had forgotten to port forward 443… I realized when looking over my open tabs and noticing I still had the port forward page open on my router page since last week, all filled in, I just forgot to save. :slight_smile: