The browser will gladly reuse an http2 connection with a resolved IP address. If you happen to have many subdomains pointing to a single ingress / reverse proxy that returns the same certificate for different Host headers, you can very well end up in a situation where the traffic will get messed up between services. To add to that - debugging that stuff becomes kind of wild, as it will keep reusing connections between browser windows (and maybe even different Chromium browsers)
I might be messing up technical details, as it's been a long time since I've debugged some grpc Kubernetes mess. All I wanted to say is, that having an exact certificate instead of a wildcard is also a good way to ensure your traffic goes to the correct place internally.
https://github.com/kubernetes/ingress-nginx/issues/1681#issu...
> We discovered a related issue where we have multiple ssl-passthrough upstreams that only use different hostnames. [...] nginx-ingress does not inspect the connection after the initial handshake - no matter if the HOST changes.
That was 5-ish years ago though. I hope there are better ways than the cert hack now.
If you close that tab and bring it back with command+shift+t, it still will fail to make that connection.
I noticed sometimes it responds to Close Idle Sockets and Flush Socket Pools in chrome://net-internals/#sockets.
I believe this regression came with Chrome 40 which brought H2 support. I know Chrome 38 never had this issue.
All subdomains which are meant for public consumption are at the first level, like www.example.com or blog.example.com, and the ones I use internally (or even privately accessible on the internet, like xmpp.something.example.com) are not up for discovery, as no public records exist.
Everything at *.something.example.com, if it is supposed to be privately accessible on the internet, is resolved by a custom DNS server which does not respond to `ANY`-requests and logs every request. You'd need to know which subdomains exist.
something.example.com has an `NS`-record entry with the domain name which points to the IP of that custom DNS server (ns.example.com).
The intranet also has a custom DNS server which then serves the IPs of the subdomains which are only meant for internal consumption.
Regarding the certificates, if you don’t want to set up stuff on clients manually, the only drawback is the use of a wildcard certificate (which when compromised can be used to hijack everything under something.example.com).
An intermediate CA with name constraints (can only sign certificates with names under something.example.com) sounds like a better solution if you deem the wildcard certificate too risky. Not sure which CA can issue it (letsencrypt is probably out) and how well supported it is
Security by obscurity while making the actual security of endpoints weaker is not an argument in favour of wildcards...
Something like *.for-testing-only.company.com?
I guess you can use a pattern like {human name}.{random}.internal but then you lose memoribility.
