Me: ssl conn cannot be esrablished. Cert is not signed

Sr. Dev/architect: what url are you calling?

Me: dns_name:port

sd/a: yeah, I know that. But what is the url?

Me: *how the f... Did you get 'sr' and 'arch' titles, man???*
Me: why does it matter?

Sd/a: certificates depend on a url. Our LB selects a cert according to a request url

me: *buddy, I like you but I no longer look at you with respect like I used to before today...*

Well... yes. But nginx and ingress controllers can select which cert to return "dynamically".
You are probably missing an ingress rule for the specific path you are looking at, and getting the "wrong" nginx instance.

I have the same issue with my clusters.

@magicMirror so you too are passing an url [i.E. Http request] via an insecure channel, i.E. Plain-text??

Wtf is wrong with you people...

@magicMirror not to mention, this is not how ssl works. You cannot negotiate a secure channel after you transfer the data. There's no point to any more..

@netikras
Not me. I am aware of the issue, but it was not my call to make. Fixing it.... is pretty much impossible. Also - my specific case involves a wildcard multihost SAN field cert.

I know it looks stupid, but that how it works.
check this for more details, on how this shit works:
https://cloud.google.com/kubernetes...

@magicMirror this link mentions no such thing. It explicitly says that an lb MUST have its own certificate. Not dynamic or depending on a url or anything. 1 lb == 1 cert.

What happens after my ssl termination - that's a different story

@jespersh reneg is possible AFTER a secure channel is already established. So I need to establish the initial secure channel first.

What if the machine loadbalances for several domains with different ssl certs? It has to know which cert to serve. And knows that thanks to SNI header field sent during the ssl handshake.

I, too, cannot debug an application error when a lb redirects my request to who knows where, as I didn't sent required SNI along the way, only an IP:port combo.

@Aldar That is actualy the case :) But SNI has nothing to do with URL anyways..

@netikras I both get where you're coming from, and would strangle someone going after such small wording issues xD

The thing is, as a sysadmin, I gotta go observe the issue myself, and if I spent 5 minutes arguing about word specifics rather than getting the frikin url to test, that's 5 minutes of time wasted, as it taught me nothing and produced no result.

Though... A sysadmin and a programmer both should know what SNI is, and where it plays role, agree on that.