An error Wildcard Certificate not Trusted byNSX Advanced Load Balancer might be observed for a wildcard certificate bound to a virtual service.

The following is an example for a wildcard certificate not trusted by NSX Advanced Load Balancer.

The virtual service is associated with a wildcard SSL certificate with the common name (CN) set to *.abc.example.com and the Subject Alternative Name (SAN) value set to abc.example.com. Though HTTPS access to abc.example.com is trusted by NSX Advanced Load Balancer, the domain globaldev.abc.example.com is not trusted. DNS resolution for *abc.example.com and abc.example.com returns the IP address of the configured virtual service.

Resolution

The certificate used in the example is a wildcard certificate and has a SAN filed with the DNS name set to abc.example.com.

To resolve the issue, set the SAN field with an asterisk mark (*) as shown below. Once the SAN field is modified, client browser will validate the certificate as a wildcard certificate.

DNS Name – *.abc.example.com.

Additional Information

For more information on how to verify the domain when certificates have a SAN field, see Subject Alternative Names: Compatibility.

If an SSL Certificate has a Subject Alternative Name (SAN) field, SSL clients are supposed to ignore the Common Name value and seek a match in the SAN list. This is the reason why DigiCert always repeats the common name as the first SAN in our certificates.