Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP_METHOD=nohttps requires CERT_NAME set to work in some cases #766

Closed
G-E-N-E opened this issue Mar 14, 2017 · 2 comments
Closed

HTTP_METHOD=nohttps requires CERT_NAME set to work in some cases #766

G-E-N-E opened this issue Mar 14, 2017 · 2 comments

Comments

@G-E-N-E
Copy link

G-E-N-E commented Mar 14, 2017

This might just be something to add to the documentation...

I have a wildcard certificate used by a couple virtual hosts which require https (redirect).
When I went to spin up a new virtual host which requires that only http be used (HTTP_METHOD=nohttps) I was surprised to find that I ended up getting a 503. The virtual host
I was attempting to spin up also matched the wildcard certificate which as far as I can tell is what
causes the issue.

The issue can be easily fixed by adding CERT_NAME=<invalid cert name> but it wasn't documented that this would work and it wasn't obvious.

I think it's a bug that a valid cert overrules the HTTP_METHOD=nohttps.

@thomasleveil
Copy link
Contributor

thomasleveil commented Mar 15, 2017

You should provide the /etc/nginx/certs/default.crt and /etc/nginx/certs/default.key files. With those, attempts to query that nohttps vhost will be answered with HTTP status code 500.

The relevant part in the documentation is § How SSL Support Works:

The default behavior for the proxy when port 80 and 443 are exposed is as follows:

  • If a container has a usable cert, port 80 will redirect to 443 for that container so that HTTPS is always preferred when available.
  • If the container does not have a usable cert, a 503 will be returned.

Note that in the latter case, a browser may get an connection error as no certificate is available to establish a connection. A self-signed or generic cert named default.crt and default.key will allow a client browser to make a SSL connection (likely w/ a warning) and subsequently receive a 503.

(and yes the README says 503, but the actual code is 500 in the nginx conf - #767)

thomasleveil added a commit to thomasleveil/nginx-proxy that referenced this issue Mar 15, 2017
rhansen added a commit to rhansen/nginx-proxy that referenced this issue Jan 7, 2023
Before, when `HTTPS_METHOD` was set to `nohttp`, one or two plain http
server entries were created anyway:

  * A catch-all fallback server that always returns 503.  Always
    created to handle requests for vhosts not otherwise defined.
  * When the vhost-specific certificate is missing, a plain http
    equivalent of the https vhost that would have been created had the
    certificate existed.  (Maybe this was created to help
    `acme-companion`, or maybe it was an oversight.)

Similarly, when `HTTPS_METHOD` was set to `nohttps`, https server
entries were possibly created anyway:

  * A catch-all fallback server that always returns 503.  Created when
    a default certificate exists to handle requests for vhosts not
    otherwise defined.
  * A vhost that always returns 500, created when a default
    certificate exists but a vhost-specific certificate does not.

This commit eliminates these servers, bringing the behavior in line
with the documentation and user expectation.  It also makes it easier
to implement a new feature: different servers on different ports.

Fixes nginx-proxy#766.
rhansen added a commit to rhansen/nginx-proxy that referenced this issue Jan 7, 2023
Before, when `HTTPS_METHOD` was set to `nohttp`, one or two plain http
server entries were created anyway:

  * A catch-all fallback server that always returns 503.  Always
    created to handle requests for vhosts not otherwise defined.
  * When the vhost-specific certificate is missing, a plain http
    equivalent of the https vhost that would have been created had the
    certificate existed.  (Maybe this was created to help
    `acme-companion`, or maybe it was an oversight.)

Similarly, when `HTTPS_METHOD` was set to `nohttps`, https server
entries were possibly created anyway:

  * A catch-all fallback server that always returns 503.  Created when
    a default certificate exists to handle requests for vhosts not
    otherwise defined.
  * A vhost that always returns 500, created when a default
    certificate exists but a vhost-specific certificate does not.

This commit eliminates these servers, bringing the behavior in line
with the documentation and user expectation.  It also makes it easier
to implement a new feature: different servers on different ports.

Fixes nginx-proxy#766.
@buchdag
Copy link
Member

buchdag commented May 10, 2023

This should have been fixed by #2186

@buchdag buchdag closed this as completed May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants