Does Couchbase SDK hostname verification fail when the node certificate SAN omits the bootstrap hostname?

Couchbase SDKs use couchbases:// for encrypted connections and validate the server certificate chain and hostname during the TLS handshake. The uncertainty is which hostname the SDK compares against the certificate's Subject Alternative Names (SAN) when the address used for bootstrap differs from the addresses the cluster advertises later.

Several conditions complicate this: DNS SRV bootstrap can return aliases that resolve to node addresses, topology refresh can advertise node hostnames or IP addresses that differ from the bootstrap address, and default self-signed certificates may not list every address in their SAN entries. Trust-store configuration also differs across SDK languages and versions, so verification behavior is not necessarily portable between them.

1. Does hostname verification fail when the node certificate SAN does not include the bootstrap hostname used in the connection string?
2. During topology refresh, is the certificate validated against the bootstrap address or against the node address the cluster advertises?
3. Which SAN entries must a cluster certificate contain so verification succeeds across bootstrap, DNS SRV aliases, and refreshed topology addresses?