Serving on a interface that isn't specified inside the configuration file

[Starz0r]

Before, I was not really sure where to post this between Caddy, Portainer, Let's Encrypt forums, and here, but I think after my findings today, I think opening the issue here is the best course of action.

Currently I'm experiencing an issue where using this image in Docker deployed from a Portainer interface gives me some issues, and has the Caddy executable exiting even though my certificates are returned successfully. I can successfully reproduce the issue on an DigitalOcean droplet on Debian 9.5 for x86-64 by pulling the image and running it, then editing the Caddyfile as follows and restarting the container.

docker.domain.tld {
     tls username@domain.tld

     proxy / localhost:port {
          transparent
          websocket
     }
}

Restarting with this configuration yields the following issue that ends up in the logfile.

urn:ietf:params:acme:error:malformed - Error creating new order :: DNS name does not have enough label

This error is pretty generic, and searching around for it yield not many result. But after many hours researching and asking around I came to the conclusion that this error is from this image ignoring some of my Caddyfile settings. When I attach a shell to the container and look for my certs, I can find that they are sent over successfully, meaning there is no issue there, so it seems that this image might have some defaults of it's own that still have some priority.

I have a big suspicion that this image is requesting a cert for either localhost or 0.0.0.0 or 127.0.0.1, which are all invalid by ACME standards. I'm not really sure why this is, even after I set my own Caddyfile which removes the 0.0.0.0 entry from the top of the file. Is there any way I can prevent it from attempting to register an invalid domain name? Everytime it does this, Caddy exits instead of just staying alive and not serving requests to that IP, meaning it will never actually try serving from interfaces I actually want.

[abiosoft]

Hmmm. The image has a default Caddyfile at /etc/Caddyfile and that can easily be overridden by mounting yours in the same path or specifying the --conf flag.

How are you starting the docker container, are you using a compose file?

[Starz0r]

I'm editing the default Caddyfile at /etc/Caddyfile with my desired settings.

The Docker container is started as normal from pulling it and just running it with all the default commandline arguments the image came with (although ACME-AGREE is set to true here).

[abiosoft]

I'm editing the default Caddyfile at /etc/Caddyfile with my desired settings.

Just for clarity, how are you doing this? Do you have the path mounted as a volume?

[Starz0r]

I attach a shell (standard sh in this instance), and used a TUI Text Editor like GNU Nano to edit the file with the proper correct settings. However, this has the side effect of not be "consistent" in the ways I listed in the Original Post, as it still attempts to serve from 0.0.0.0, despite no longer present in the Caddyfile.

[abiosoft]

The reason I'm asking is that attaching a shell after starting the container is not gonna have an effect. Caddy has already started with the Caddyfile on disk before your edits. Except you restarted Caddy afterwards or you start Caddy inside the attached shell.

[Starz0r]

I'm not sure what you are getting at.

Are you saying that editing the config file at /etc/Caddyfile, then restarting the container so changes take effect is not the recommended way to do this? (Despite that the changes go through, it's just the fact that 0.0.0.0 persists regardless).

[Starz0r]

@abiosoft Yeah, it's an issue with this container. I decided to do a test by manually by obtaining the certificates and keyfile by hand, then asking Caddy to load it instead of giving it my email. The default behavior would be for this to successfully load my certs, then do nothing else, instead it loads my certs successfully AND does something else, which I'm not entirely sure of. I think it's trying to grab a certificate for 0.0.0.0, but Let's Encrypt isn't keen on giving me the info on what site was attempted or what the info on the attempt was.

So yeah, it's something with the default behavior on this container. I hope this can be fixed soon!

[Starz0r]

It appears that it is an issue with Global Directives since as soon as a Scoped Directive is brought in, it no longer works and causes some odd behavior. The maintainers over at mholt/caddy have assured me that this isn't a "bug" but just how directives work https://github.com/mholt/caddy/issues/2314.

I'm rather skeptical of not calling it a bug, as it produces unwanted behavior, but since I've resolved the issue, I see there is no point to keep this GitHub Issue open.

[francislavoie]

@Starz0r Just for next time, I suggest you post your full Caddyfile when opening issues like this one, it would've been simple to spot what the problem was and I'm sure @abiosoft would've pointed it out if you included your error/log directives. If you don't give the full picture it becomes hard to guess what might've gone wrong because we have to make assumptions based on the info you provided. Glad we found your issue eventually though!