SSL cert not containing API VIP URL as SAN for new vSphere IPI deployments

[stolencode]

on a new vSphere IPI deployment of OKD, tested on the latest 4.10.x build as well as the previous two 4.9.x builds, I'm getting the following error:

x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, openshift, openshift.default, openshift.default.svc, openshift.default.svc.cluster.local, 172.30.0.1, not api.okd.cudanet.org

The kubernetes api is up and listening, and inspecting the cert does show that it is valid for the SANs mentioned above, but not for the URL I specified for the API VIP. I tested this out from a Linux host and a mac, same behavior. My Openshift 4.10.3 cluster has no such problem. Grasping at straws, I double and triple checked that the root CA and vSphere trusted root cert are installed (they are, otherwise Openshift wouldn't work either and I'd get a different SSL error).

[rvanderp3]

By chance, is there anything(such as a load balancer) between where you are seeing this error and the API VIP? It almost looks like the SNI tag for the public API is being stripped before the connection reaches the VIP. The API server can return different certs based on the SNI tag.

[stolencode]

As a matter of fact... there was. I had an haproxy lb running on my router (pfSense) from when I was doing some testing on Openshift 3.11 a while ago. But I don't see how that could have had any effect on the OKD 'openshift-install' binary only and not the official Openshift 4.10.x binary. Also complicating things... on my Mac (so should not theoretically have any effect on the RHEL 8 box) I had a traefik instance running in docker. Both have been disabled now and I'm trying to spin up the cluster again. I'll report back in ~30 minutes whether I was successful. It's never been a problem in the past, but it is worth noting this is on the same VLAN as my 'prod' OCP cluster. At one point, I had my main OCP cluster, an OKD cluster and OCP3.11 all running on the same subnet without any issues, but who knows... I might just try throwing OKD on it's own VLAN.

[stolencode]

well... I guess I need to chalk this up to network #ItsAlwaysTheNetwork because moving OKD to it's own VLAN the problem went away. ¯_(ツ)_/¯