Manually replace expired user supplied SSP ingress certificate

Products

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

Issue/Introduction

When user supplied SSP ingress certificate expires, SSP becomes inaccessible through both UI and API, making replacing the expired ingress certificate through UI or API impossible

Environment

SSP 5.1 and above where user-uploaded ingress certificate has expired.

Cause

SSP versions 5.1 and beyond allow user to replace system-generated ingress certificate with one signed by user's own CA.  Even though SSP provides monitoring and alarming supports to warn users to take action when said certificate expiration date approached, it depends on user heeding the alarms and taking actions to replace the certificate.  SSP can not replace the certificate for users since SSP does not control user's signing CA.  As a result, after the certificate expires, SSP becomes inaccessible via UI or API even if users ignore the expired certificate error in their clients (e.g., browsers or postman.)

After the user supplied ingress certificate expires, user will observed the UI stops working with error code 403 from the browser.  Likewise, when trying to make API calls to the ingress FQDN, API calls will failed with HTTP response code of 401.

authserver container will also contain logs about authetination failed due to expired certificate as below :

Login to SSPI cli  using sysadmin user and  verify the authserver logs using the command :

 k -n nsxi-platform logs deploy/authserver

 

Error snippet from logs: 

 

2025-07-20T02:16:37.207Z ERROR UnifiedChecker check failed {"request_id": "7b95199f-fcda-484e-854e-00bc7667fa76", "auth_type": "local", "host": "", "method": "GET", "path": "/ssp/trust-management/self", "principal": "", "error": "Post \"https://ssp.example.com/authelia/api/authz/ext-authz\": x509: certificate has expired or is not yet valid: current time 2025-07-20T02:16:37Z is after 2025-07-20T02:00:00Z"} vmware.com/nsx/intelligence/platform/authserver/pkg/auth.(*UnifiedChecker).check platform/authserver/pkg/auth/unifiedchecker.go:322 vmware.com/nsx/intelligence/platform/authserver/pkg/auth.(*UnifiedChecker).Check platform/authserver/pkg/auth/unifiedchecker.go:286 vmware.com/nsx/intelligence/platform/authserver/pkg/auth.(*authV3).Check platform/authserver/pkg/auth/server.go:46 github.com/envoyproxy/go-control-plane/envoy/service/auth/v3._Authorization_Check_Handler external/com_github_envoyproxy_go_control_plane_envoy/service/auth/v3/external_auth_grpc.pb.go:85 google.golang.org/grpc.(*Server).processUnaryRPC external/org_golang_google_grpc/server.go:1405 google.golang.org/grpc.(*Server).handleStream external/org_golang_google_grpc/server.go:1815 google.golang.org/grpc.(*Server).serveStreams.func2.1 external/org_golang_google_grpc/server.go:1035

 

Resolution

1. Temporarily revert back to system generated ingress certificate in cloudnative-platform-ingress httpproxy,  From SSPI command line

k -n nsxi-platform patch httpproxy cloudnative-platform-ingress --type='merge' -p '{"spec":{"virtualhost":{"tls":{"secretName":"ingress-tls-cert"}}}}'

2. Now UI accessible and user can replace ingress via UI using CSR → upload certificate workflow.  Note that even though SSP has switched to use system generated ingress certificate, in Certificates UI page, one continue to see the user provided ingress certificate is being used and has expired. 

3. Once a new ingress certificate gets uploaded to SSP successfully, there's no need to revert the above setting as the system will make sure it's properly configured.