companion bugs default https host for nginx proxy

[ipepe]

Hi. I noticed that when using companion (separate containers scenario) there are no default.key and default.crt in /etc/nginx/certs/ and that makes nginx.tmpl to not generate a default https (and first) 'server' in configuration that would respond with 503. Because of that, when creating such stack, anyone can query my server on https by ip and nginx will respond with first valid https configuration, and not 503 like it should. How can we fix this?

Steps to reproduce:
Start 3 separate containers like in readme: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion/blob/master/README.md#separate-containers.

Then start a whoami container:

sudo docker run -d --name whoami -h whoami -e VIRTUAL_HOST=whoami.local -e LETSENCRYPT_HOST=whoami.local -e LETSENCRYPT_EMAIL=letsencrypt@local.local LETSENCRYPT_TEST=true --restart=unless-stopped -i -t -P jwilder/whoami

And reach that server but not by whoami.local, reach it on localhost or IP Address. It will respond with whoami.local. It works fine on port 80 (responds with 503), but on 443 it will load whoami server.

[buchdag]

Hi.

Correct me if I'm wrong, but I think the same thing would happen even if one does not use letsencrypt-nginx-proxy-companion at all and just manually put certificates on the /etc/nginx/certs folder as described in the nginx-proxy doc.

[ipepe]

Yeah, I think You are right. Today I figured out how to setup this correctly, although it would be nice to have this information in readme or somewhere.

So basically I change my claim on this issue from "Bug" to "Needs more information in Readme"

EDIT: Solution: I mean that after starting all containters for nginx-proxy and companion, I should copy (generated by myself) certificate files default.key and default.crt into /path/to/certs

[buchdag]

Contributions to the project's wiki are welcome :)

[vicary]

I guess my issue #411 is describing the same thing, but I am not sure if we should simply document this and call it a day.

Making up some invalid placeholder certs for default doesn't quite make sense in production.

I see that users of nginx-proxy is very likely to start without a valid default upstream, and may never will.

How about disabling access to default server in the default template for nginx-proxy and rely solely on VIRTUAL_HOST? Users do need a default upstream can always override it with a separate docker-gen container.

[buchdag]

@vicary for clarity sake I'm going to close this issue so we can focus the discussion on #411