(Custom) domain with no certificate still serves https

[nathansamson]

Steps to reproduce:

• Install deis v 1.13
• Create 2 applications (a and b)
• Add a custom domain to both applications (a.example.org and b.example.org)
• Add a https certificate to one of the domains (b.example.org)
• Access https://a.example.org

See that the connection is accepted but served with the certificate for b.example.org. After accepting the exception of the invalid certificate in your browser traffic will be served by application B instead of application A.

An example can be seen in https://fiesta-mundial.beeple.eu/ vs http://fiesta-mundial.beeple.eu/

I am not sure what an acceptable solution would be, but I would suggest either a "connection not accepted / reset" or if this is not possible in nginx router configuration a 404 when accessing the domain over HTTPs if no certificate is set.

I have not tested this but either this also will occur in deis/router (deis V2); or an updated nginx configuration should be relatively easily translatable to Deis V1 as the only significant change in router component (AFAIK) is how the config is generated and not the possibilities of the configuration (at least as far as HTTPs is concerned)

[nathansamson]

Note the app which serves HTTPs is just the first application in the nginx configuration with a certificate; this feels rather arbitrary.

Note that I am personally confused by this nginx behaviour as the server_name clearly states it should not serve that request.

So the easiest solution(it seems) would be to prepend a fallback server entry with a self signed certificate for a nonsense domain (eg localhost) which then serves a hardcoded 404. This will (obviously) still trigger the browser warnings about wrong certificate (and/or self signed certificate) but at least would not confuse users by sending traffic to the wrong application.

[bacongobbler]

@nathansamson can you post the nginx.conf inside the router for debugging? I'm fairly certain this is already fixed in v2, and the issue here in v1 is simply due to the hard-to-test templating logic.

[nathansamson]

@bacongobbler I've sent you an email with requested config.

I shared this privately with you because it contains domain names which you can guess our clients of which I prefer not to have in public. Feel free to share internally with your collegues when needed, as I have anonymized the most important data anyway.

Please let me know if you need anything else.

I am happy to test a test router image if needed as well

[nathansamson]

@bacongobbler Did you have any chance to look at this?

If not can you give a hint of how a typical server entry is supposed to loolk (both https and non https enabled); and (if any) global config entries are needed?

[bacongobbler]

Sorry, I wasn't able to see anything out of the ordinary. I don't believe this is an issue on v2, just with v1.

[krancour]

So the reason this happens is that when a default virtualhost isn't specifically identified (for a given port; in this case 443), the first virtualhost automatically becomes the default.

fwiw, this exact behavior was reported early on for router v2 and was solved using the exact solution suggested here. We explicitly designated a default virtualhost with a self-signed cert. This became a "junk drawer" for responding with a 404 to requests that didn't match some other non-default vhost / application.

I'll leave it up to @bacongobbler and @mboersma whether they think it is worth backporting that improvement to Deis v1.x.

[deis-admin]

Deis v1 LTS support ends February 13, 2017, and v1.13.4 is intended to be the last official release, so I'm closing this.

Please see Deis Workflow, the documentation / hub repository for the next-generation PaaS.