NSX Client Certificate Prompt with Smart Card Root Cert Due to SSP Ingress Certificate

Products

• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

After completing authentication through VMware Identity Manager (vIDM) and being redirected back to NSX, users are unexpectedly prompted to select a client certificate in their browser. This prompt interferes with normal access and cannot simply be dismissed by selecting the displayed smart card certificate.

Ex: 

• Users see a certificate selection prompt after vIDM authentication completes.
• Selecting a smart card certificate causes an authentication error — there is no NSX principal identity associated with the smart card cert.
• Users must cancel the prompt to proceed, which can be confusing and may block access if the browser enforces a selection.

Scope: Applies only to deployments using smart card authentication.

 

Environment

• All supported NSX versions
• SSP 5.x
• NSX ingress/VIP certificate and smart card certificates share the same Root CA

Cause

The issue originates from how SSP creates a principal identity for NSX during integration. SSP uses the ingress/VIP certificate as the authentication certificate for this principal identity. Because this ingress certificate is signed by the Root CA, NSX advertises that CA as an acceptable authority for client certificate authentication.

When users' smart card certificates are also signed by that same Root CA, browsers interpret the server's CA advertisement as a request for a matching client certificate and prompt accordingly.

Resolution

There is no single mandatory fix. The options below address the issue at different levels of the stack. Choose the one that best fits your environment's security policy and operational constraints.

Each option breaks one link in that chain: Option 1 removes the CA overlap, and Option 2 prevents the browser from acting on the match.

Option 1 — Use a Different CA for Server Certificates (Recommended Where Feasible)

The cleanest long-term resolution is to ensure the NSX ingress/VIP certificate and the smart card certificates are signed by different CAs. When the two certificate chains are distinct, NSX does not advertise a CA that matches the smart card, and the browser does not prompt.

Note: This requires a change to PKI/CA configuration. Coordinate with your security or PKI team before making changes. This option may not be feasible in environments that use a single unified Root CA.

Option 2 — Browser-Level Client Certificate Policy (Enterprise Managed)

Enterprise browsers can be configured to suppress the client certificate prompt for specific URLs. This approach requires no changes to the certificate infrastructure and can be deployed through group policy or MDM.

Important: Browser certificate policies vary by vendor, version, and platform, and they affect every site the policy pattern matches — not only NSX. Review these settings with your Active Directory or endpoint management team, and validate the behavior in a test environment before deploying broadly.

Chromium-Based Browsers (Google Chrome / Microsoft Edge)

Chrome and Edge prompt for a client certificate when a site requests mutual TLS authentication and the operating system certificate store contains one or more certificates matching the server's stated criteria.

Default behavior:

• If one or more valid certificates match the server's criteria, a selection dialog is shown.
• If no valid certificates match, no prompt is shown. The browser completes the handshake without a client certificate, and the server decides whether to allow the connection.
• The browser caches the selected certificate for the session. Changing the selection generally requires restarting the browser.

Enterprise policy — AutoSelectCertificateForUrls

Administrators can use the AutoSelectCertificateForUrls policy to control client certificate selection for specific URLs without user interaction. The policy takes a URL pattern and a filter that determines which certificates the policy applies to.

Confirm the exact syntax and behavior against current Chrome and Edge enterprise documentation before deploying. In particular, verify whether your configuration causes the browser to submit a certificate or to proceed without one — a policy that auto-submits the smart card certificate produces the same authentication error as selecting it manually, and removes the user's ability to cancel.