MicroShift uses a variety of certificates to work, most of them for internal use within the cluster. In order to verify these certificates there are different Certificate Authorities to sign and then validate against them. On top of that there is a hostname verification too, based on the Common Name (CN) and Subject Alternative Names (SAN) fields in an x509 certificate. There is also Server Name Indication so the client is able to send a virtual domain for the server to select the correct certificate (according to CN/SAN).

Client-go does not use SNI, it accesses apiserver by the service network IP, which means it needs to match a certificate based only on the IP. If the internal apiserver certificate includes the node IP then this one will get served everytime a client tries to connect to it. This includes external access. When an external client connects to the apiserver using the IP it will get this same certificate, which is signed by an internal CA and not the one in kubeconfig. This returns an error. If the node IP is included in the external certificate then the same thing happens to internal access, it is signed by an unknown CA.

Given that any node IP use alternative in certificates renders broken connections, hostnames must be used. Relying on hostnames does come with other limitations, such as requiring using DNS resolution for external certificates. Internal ones may resolve everything through localhost.

By the nature of the devices where MicroShift is installed the node IP or hostname may change anytime. If certificates depend on the hostname then the same issue can happen if certificates are not regenerated. There are several ways of solving this:

• For external access, SANs may be injected, which can be independent of the hostname.
• For internal access, a special name can be used with an entry in /etc/hosts. For single node cases, localhost should suffice. For more than one node (or single), this special name would survive any hostname change and would need to be updated on IP changes.

Kubelet and mDNS components also need to be restarted if IP/hostname change.

Keep in mind that node name and hostname are decoupled, and once the node name has been established it can not change (https://issues.redhat.com//browse/USHIFT-573).