Oracle SSL_LISTENER Hostname Verification Defaults to Disabled Across On-Premises Deployments

Configuration Gap in Certificate Validation

Oracle Database listeners configured for TCPS accept connections without validating the server certificate's distinguished name against the hostname used in the connection string. The SSL_SERVER_DN_MATCH parameter in sqlnet.ora controls this behavior and defaults to FALSE, meaning hostname verification is effectively opt-in for on-premises installations.

Constraints and Uncertainty

Modern certificates rely on Subject Alternative Name (SAN) extensions rather than Common Name (CN) for hostname identity. When SSL_SERVER_DN_MATCH=TRUE, Oracle performs a strict DN match that may not honor SAN entries unless the CN exactly matches the hostname, creating validation failures for correctly issued certificates. Additionally, Oracle Cloud Autonomous Database enforces hostname verification by default, while on-premises deployments require explicit configuration, resulting in inconsistent security postures across environments.

There is no built-in automated mechanism for certificate revocation checking (CRL or OCSP) without external tooling, leaving revocation validation as a manual operational task.

Questions

1. What is the documented behavior of SSL_SERVER_DN_MATCH=TRUE when the server certificate contains only SAN entries and no matching CN?
2. Can hostname verification be enforced globally for all PDBs in a multitenant container without per-PDB sqlnet.ora overrides?
3. Is there a supported method to enable automated CRL or OCSP validation within the Oracle Wallet framework without external scripts?