Consider replacing the default self-signed certificates for components, where possible, to improve the security of SSL/TLS connections to those components.

The security of the environment depends on the validity and trust of the management component certificates. As a best practice, you replace certificates in the following cases:

  • Before certificates expire.

  • When a certificate is compromised.

  • When the attributes related to a certificate change. For example, when the host name or the organization name change.

The certificate replacement process consists of the following phases:

  1. Complete the process for creating a certificate signing request (CSR) for the Supervisor Kubernetes API endpoint in the vSphere Client.

  2. Use the CSR to generate a CA-signed certificate.

  3. Import the certificate in the vSphere Client.

For step-by-step instructions for this process, see GUID-2D56E6F4-8E91-45FC-BC45-3448D54AAF5D.html.

After the certificate replacement process has been completed, you can successfully connect to the Supervisor Kubernetes API endpoint using kubectl without specifying the --insecure-skip-tls-verify option as the signed certificate is used to encrypt communications over TCP/443 and TCP/6443.