All vhosts redirect to https

[maxkueng]

I switched from jwilder/nginx-proxy to dmp1ce/nginx-proxy-letsencrypt and it works really great. Thanks!

But I've noticed that all requests are now redirected to https regardless of whether the LETSENCRYPT_HOST variable is set on the backend container. This makes impossible to have non-https sites.

Is this behavior intentional? jwilder/nginx-proxy only redirects to https if there is a key and a certificate available. I think it would be nice to keep this functionality and only enable the https redirect if there key and certificate are present.

My suggestion is:

• By default serve over http without redirect
• If the .key and .crt files are present, enable the https redirect
• If LETSENCRYPT_HOST and LETSENCRYPT_EMAIL are present, automatically obtain a certificate and enable the https redirect.

[dmp1ce]

It should work the same as jwilder/nginx-proxy for redirecting to HTTPS. Perhaps your browser cached "Strict-Transport-Security" for the website and now redirects to HTTPS automatically no matter what. jwilder/nginx-proxy does use "Strict-Transport-Security" for HTTPS which will tell the browser to always use HTTPS on future visits.

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Can you reproduce the redirect on a new website or after clearing the browser cache of HTTP Strict Transport Security?

There is #12 which points out that nginx-proxy tries to match the closest certificate which could be what is happening to you.

[JrCs]

@dmp1ce yes i think that the nginx proxy must not match the closest certificate.
Can you try replacing:

{{/* Get the best matching cert  by name for the vhost. */}}
{{ $vhostCert := (closest (dir "/etc/nginx/certs") (printf "%s.crt" $host))}}

with

{{ $vhostCert := printf "%s.crt" $host }}

[dmp1ce]

@JrCs Yes, I think that is the fix.

If you wanted a the following domains:

• example.com
• encrypted.example.com

And example.com is supposed be http only, then I think it would match encrypted.example.com and try to use that certificate making it https.

I'll test it tomorrow.

[maxkueng]

I don't think it has anything to do with Strict-Transport-Security or anything client-side.

When I run (replace "my-proxy-container" with actual container name)

docker exec my-proxy-container grep -vE '^\s*$' /etc/nginx/conf.d/default.conf

the redirect does show up in the config file. However, the server name of the non-SSL site is actually a subdomain of another site with SSL so there could be a connection to #12.

This is what I was looking for:

• example.com, www.example.com (SSL)
• banana.example.com (no SSL)

But http://banana.example.com/ redirects to https://banana.example.com/ and the browser (obviously) complains about an invalid certificate.

[dmp1ce]

@maxkueng Why not add a Let's Encrypt certificate for banana.example.com? Why do you want to keep it with no SSL? I'm just curious.

Also, I agree that this is a bug but I think it should probably be addressed in jwilder/nginx-proxy. Here is the issue with a workaround: nginx-proxy#182

Can you try setting -e CERT_NAME="" for banana.example.com?

[JrCs]

@dmp1ce about not using the "closest" certificate file i think we can't remove it because it will change the behavior for certs not created by letsencrypt.
So the best actually is perhaps to use the tip with CERT_NAME=""

[maxkueng]

I did eventually end up using SSL for all sites. I guess setting CERT_NAME would work but it's counter intuitive. You should only have to set CERT_NAME if the file name doesn't match the expected file name.
Also that it uses the "closest" key/cert is something nobody would expect and will always cause people trouble if they don't know about it. A way to partially fix this would be to use the closest match only if the cert also works with the specified host names.

[JrCs]

If you use LETSENCRYPT_HOST it will create a cert specific to the domain so the "closest' key/cert will work because it will match exactly the domain(s) defined in LETSENCRYPT_HOST. In other case (certs not created by letsencrypt) it will try to find the best "closest" cert(s)