An engineer is requesting an SSL certificate for a VPN load-balancing cluster in which two Cisco ASAs provide clientless SSL VPN access. The FQDN that users will enter to access the clientless VPN…

Although the wildcard CN=*.example.com would syntactically match all three FQDNs, modern browsers rely on SAN entries for validation - the SAN in this option lists only asa.example.com, so redirected connections to asa1.example.com or asa2.example.com would trigger certificate name mismatch errors.

Users access the VPN using the FQDN asa.example.com, not an IP address; a CN set to an IP would fail FQDN-based validation, and asa.example.com is absent from the SAN entries making the cluster address itself invalid.

Modern TLS clients validate server identity against SAN entries, not the CN field. Including asa.example.com, asa1.example.com, and asa2.example.com in the SAN means the same certificate installed on both ASAs will pass validation whether the browser is connecting to the cluster address or either individual ASA address after redirection. The CN=asa.example.com represents the primary entry point while the SAN covers all redirect targets, satisfying the no-errors requirement for every possible connection path.

Certificates with only IP address SAN entries fail validation when clients connect via FQDN, which is the documented user-facing access method in this scenario.