301 Moved Permanently

[jareware]

According to the docs:

If a container has a usable cert, port 80 will redirect to 443 for that container so that HTTPS is always preferred when available

Preferring HTTPS over HTTP makes a lot of sense, but that redirect is implemented as 301 Moved Permanently. I just landed in a bit of hot water after temporarily enabling HTTPS support, and moving back to HTTP when things didn't work out, but several clients had already seen the permanent redirect and wouldn't even consult the HTTP endpoint anymore.

Given the dynamic nature of containers coming and going, would it be a safer option to redirect with 302 Moved Temporarily?

[wader]

Also note that a Strict-Transport-Security header is added by nginx-proxy which could cause this

[jareware]

Just did a factory reset for one embedded device that would otherwise never even try the HTTP endpoint again... :)

[wader]

Sounds like HSTS

[jareware]

Wouldn't a Moved Permanently have that same effect, though?

[md5]

@jareware Browsers don't pay attention to 301 v. 302 as far as I know. The only thing I've ever heard of paying attention to that distinction is search engine crawlers. And even there, I'd be surprised if they actually pay attention since developers get it wrong too often.

[jareware]

OK, in that case HSTS sounds like a lot more likely explanation... and I don't think anyone'd want to give that up?

I don't suppose there's any way to keep a specific virtual host on plain old HTTP, and serve other virtual hosts through HTTPS?

[md5]

The redirect to HTTPS and the HSTS logic are only triggered if you provide a cert for a VIRTUAL_HOST by hostname or if you set CERT_NAME on the container. The only other way that HTTPS would be enabled is if you provided default.crt, in which case you wouldn't get the redirect to port 443 and if you did hit port 443 it would give a 503 error with no Strict-Transport-Security header.

So to keep a specific virtual host on plain HTTPS, you just don't provide a cert for that host. If you can explain your virtual host setup a little more fully, perhaps there's something I'm missing about your situation.

[jareware]

@md5 sure thing! So it's rather simple, I have a self-signed cert for *.foo.com, and a corresponding DNS record pointing to a machine that runs nginx-proxy. When I bring new services online, say, bar.foo.com, everything just works automatically, and I love it.

I'd also love to use nginx-proxy as an SSL termination node for all the containers running behind it, so they don't need to be aware of HTTPS, certificates and all that stuff. But since I'm using a self-signed cert, some clients that contact bar.foo.com won't allow the connection since they run in an environment I don't control, and thus can't install my cert there.

So long story short, one possible solution would be to run all containers on HTTPS except bar.foo.com, and I'm not sure how to configure that.

[md5]

@jareware You didn't mention what command you used to run jwilder/nginx-proxy and configure the SSL certificates.

[jareware]

Oh, sorry. My docker-compose.yml is:

proxy:
  image: jwilder/nginx-proxy
  ports:
    - 80:80
    - 443:443
  volumes:
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - ./htpasswd:/etc/nginx/htpasswd
    - ./certs:/etc/nginx/certs

And:

$ ls certs/
foo.com.crt  foo.com.csr  foo.com.key

[md5]

It doesn't look like what you want is currently possible, at least with that naming convention for your certificate.

The closest call in the template is going to pick up that foo.com.crt certificate for any VIRTUAL_HOST ending in foo.com. If you give the certificate a different name (e.g. wildcard.foo.com.crt), then you could use CERT_NAME=wildcard.foo.com on all the containers that you want to use it and leave off CERT_NAME on any HTTP-only virtual hosts.

[md5]

It looks like you could also hack it by adding a CERT_NAME on the HTTP virtual hosts that refers to a non-existent file. In that case, you may want to symlink your foo.com.crt to default.crt (along with the key) to ensure that the proxy serves a 503 error on HTTPS if you try to access the HTTP-only virtual hosts on HTTPS.

[jareware]

These are actually pretty good solutions, that just never occurred to me!

Assuming disabling HSTS can be dismissed as just insecure/bad idea, feel free to close this.

[jareware]

Fixed in #298