Error: Triggering precheck failed due to: failed to do request: Head - tls: failed to verify certificate: x509: certificate signed by unknown authority -seen while activating features

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

This article addresses an issue observed after replacing the SSP Installer ingress certificate on the Security Services Platform (SSP). Even after a successful certificate replacement on the SSP Installer VM, you may encounter TLS verification failures (e.g., while activating features like Security Intelligence), specifically during image pulls from internal registries or Helm chart retrieval.

The root cause involves mismatched certificates between the SSP Installer node and the platform (worker and control plane nodes), leading to certificate trust failures across the cluster.

This KB explains the background of the issue and directs you to the remediation procedure.

An error message similar to the following type is seen:
 

Triggering precheck failed due to: failed to do request: Head "https://your-ssp-installer-fqdn.yourdomain/v2/helm-charts/nsx-intelligence-precheck/manifests/5.0.0-0.0-24631124": tls: failed to verify certificate: x509: certificate signed by unknown authority

Environment

SSP 5.0

Cause

When the ingress certificate on the SSP Installer node is replaced via UI (In the backend it is typically replaced under /usr/local/share/ca-certificates/domain.crt), the new certificate gets applied locally on the SSP Installer node.

However, worker and control plane nodes in SSP are provisioned using static kubeadm templates:

• kubeadmconfigtemplates: used for bootstrapping worker nodes.

• kubeadmcontrolplane: used for bootstrapping control plane nodes.

These templates include preKubeadmCommands that inject a base64-encoded version of the SSP-I certificate into the existing and newly created nodes. Since these templates are not automatically updated during certificate replacement, any existing node or a newly scaled node will continue to trust the old, expired, or invalid certificate, resulting in TLS handshake failures when pulling images or accessing Helm charts.

• Existing running nodes do not auto-refresh certificates from SSP Installer after template updates, hence manual intervention is required to refresh their trust store.

Resolution

Please follow the steps outlined in the following Broadcom Knowledge Base article to update the certificates in the kubeadm templates and refresh the node trust configuration:
Broadcom KB 391982