Adding trusted certs to nodes on TKGS 7.0 U2

A new feature added to TKGS as of 7.0 Update 2 is support for adding private SSL certificates to the “trust” on TKG cluster nodes.

This is very important as it finally provides a supported mechanism to use on-premises Harbor and other image registries.

It’s done by adding the encoded CAs to the “TkgServiceConfiguration”. The template for the TkgServiceConfiguration looks like this:

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TkgServiceConfiguration
metadata:
  name: tkg-service-configuration
spec:
  defaultCNI: antrea
  proxy:
    httpProxy: http://<user>:<pwd>@<ip>:<port>

  trust:
    additionalTrustedCAs:
      - name: first-cert-name
        data: base64-encoded string of a PEM encoded public cert 1
      - name: second-cert-name
        data: base64-encoded string of a PEM encoded public cert 2

Notice that there are two new sections under spec; one for proxy and one for trust. This article is going to focus on trust for additional CAs.

If your registry uses a self-signed cert, you’ll just encode that cert itself. If you take advantage on an Enterprise CA or similar to sign your certs, you’d encoded and import the “signing”, “intermediate” and/or “root” CA.

Example

Let’s add the certificate for a standalone Harbor (not the built-in Harbor instance in TKGS, its certificate is already trusted)

Download the certificate by clicking the “Registry Certificate” link

Run base64 -i <ca file> to return the base64 encoded content:

Provide a simple name and copy and paste the encoded cert into the data value:

Apply the TkgServiceConfiguration

After setting up your file. Apply it to the Supervisor cluster:

kubectl apply -f ./TanzuServiceConfiguration.yaml

Notes

  • Existing TKG clusters will not automatically inherit the trust for the certificates
  • Clusters created after the TKGServiceConfiguration is applied will get the certificates
  • You can scale an existing TKG cluster to trigger a rollout with the certificates
  • You can verify the certificates exist by connecting through SSH to the nodes and locating the certs under /etc/ssl/certs:

Fix – Unable to import vCAC/vRA certificates into Orchestrator

Problem:

While in the vRealize Orchestrator Client you find that the Library/Configuration/SSL Trust Manager/”Import a certificate from URL” workflow returns an error reading “InternalError: handshake alert: unrecognized_name” when provided. The URL the resolves to the Load-Balancer VIP for the vCAC/vRA appliances.

 

Background:

Signed SSL certificate installed on vCAC/vRA Appliance, SSL Passthrough on NSX/vCNX Load-Balancer, vCAC/vRA Settings/Hostname set to resolve to VIP, matching SSL cert.

 

Fix:

  1. SSH into the vCAC Appliance as root
  2. Backup /etc/apache2/vhosts.d/vcac.conf to vcac.conf.bak
  3. Use vi to edit /etc/apache2/vhosts.d/vcac.conf
  4. Scroll down to  <virtualHost _default_:443>
  5. Add these lines

    ServerName fqdn.of.appliance.node

    ServerAlias: load.balancer.name

  6. Scroll further to ensure these params aren’t listed elsewhere, remove or revise if so.
  7. save the file and exit vi
  8. restart the vCAC/vRA services