certs: a cert attached to a particular domain appears on another

[deis]

certs: a cert attached to a particular domain appears on another

[krancour]

I'll have to look into this further, but I suspect that what is happening is that in the absence of a vhost listening on 443 for domain.two, the traffic is flowing instead to the the vhost for domain.one, because, as the only vhost listening on 443, it would be the default vhost for 443.

If you were to install platform-wide SSL using a wildcard cert, this issue would go away, because it would explicitly introduce a default vhost listening on 443 that would be a catch-all for any HTTPS traffic that didn't match any other vhost.

Note that In the absence of a platform-wide, wildcard SSL cert, it's not possible to explicitly implement a catch-all, default vhost... because what cert would we use?

I don't see this as a bug so much as just the way Nginx works. That being said, I can look into what other options might exist for simply dropping requests that aren't an exact match for any of the defined vhosts.

[krancour]

So what I could do is if a platform-wide wildcard cert has not been provided, I could use a self-signed cert for a default vhost listening on 443. It would return just return 404s. The downside is anyone requesting HTTPS for a domain that doesn't support it will get a cert warning that would stop them from ever getting the 404 (unless the willfully ignore the cert warning). But this is still probably better than the behavior you have observed.

[vdice]

I see. With the background info provided, I can proceed with writing a test using a wildcard cert to get the behavior I'm looking for. That being said, if the 'fix' sounds reasonable, apart from simply representing an adjustment to help testing (although it is nice when those happen :)), then I'd be in support of it.

[krancour]

@vdice note that providing an SSL cert for use platform-wide must be done at the time of platform installation, so it requires an addition to the chart. I'm not sure if your tests currently support that. Alternatively, I guess the manifest for it could just be submitted directly using kubectl.

Here's the doc on how it's done:

https://github.com/deis/router#default-certificate-example