Abotts Partners with singapore based tech giant to help migrate their public sector customer from Sybase to SQL server.
Abotts partners with NYPL to integrate with their partner libraries.
Upworks Inc partners with ABOTTS to build their Oracle Cloud Infrastructure (OCI) and migrate their custom applications to OCI.
Abotts Inc Partners with Gnorth consulting to deploy exadata and ODA for a large public sector customer.
Resolving ORA-17965: Hostname Mismatch in Oracle Autonomous Database Connections
Overview & Symptoms
When attempting to connect to an Oracle Autonomous Database (ATP / ADW) instance hosted on Oracle Cloud Infrastructure (OCI) via SQL Developer or Java/JDBC applications using a custom internal hostname or DNS alias, the connection fails with a security error:
Status: Failure – Test failed: ORA-17965: Host name(s): “hostname.oci.dev”
does not match the CN: “adwc.uscom-east.oraclecloud.com” or SAN(s):
“[*.adb.us-phoenix.oraclecloud.com, adb.oraclecloud.com, …]” of the server’s certificate
This prevents database client tools from establishing TCPS connections even though the credentials, network routes, and port access (1522) are completely valid.
Root Cause Analysis
This error occurs due to strict TLS/SSL Hostname Verification performed by Oracle JDBC drivers during the SSL handshake:
- Custom DNS Routing / Private Endpoints: Your connection uses a custom internal domain name (hostname.oci.dev) configured through an internal VPN or DNS proxy.
- Server SSL Certificate: The Autonomous Database server presents an official Oracle Cloud wildcard certificate (e.g., *.adb.us-phoenix-1.oraclecloud.com).
- Strict Validation Enforcement: By default, the connection descriptor includes (security=(ssl_server_dn_match=yes)). This forces the client driver to verify that the requested hostname matches the Common Name (CN) or Subject Alternative Name (SAN) on the certificate. Since .upwork is an internal private domain not on the public OCI certificate, the connection is immediately aborted.
Why does this happen suddenly?
- SQL Developer / JDBC Upgrades: Recent versions of SQL Developer and Oracle JDBC thin drivers set ssl_server_dn_match=yes as a strict default.
- OCI Certificate Rotation: Periodic cloud certificate updates by Oracle may change or narrow the certificate SAN entries, breaking connections that relied on older wildcard patterns.
The Solution
To fix this, you must explicitly instruct the driver to bypass the Distinguished Name (DN) / Hostname matching check for your internal endpoint.
Method 1: Update tnsnames.ora (Recommended)
Change ssl_server_dn_match=yes to ssl_server_dn_match=no for all service profiles in your tnsnames.ora file:
Plaintext
hostname_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=hostname.oci.dev))(connect_data=(service_name=hostname_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Method 2: Global Setting in SQL Developer
If you want to disable strict matching globally across all connections:
- Open SQL Developer and go to Tools > Preferences.
- Select Database > Advanced.
- In Add VM Options, append: -Doracle.net.ssl_server_dn_match=false
- Restart SQL Developer.
Method 3: JDBC Connection String
If connecting programmatically via Java/JDBC:
Plaintext
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=hostname.oci.dev)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=hostname_high.adb.oraclecloud.com))(SECURITY=(SSL_SERVER_DN_MATCH=FALSE)))
Security Impact
Setting ssl_server_dn_match=no does NOT disable encryption. The connection remains fully encrypted over TCPS (TLS/SSL). It simply relaxes the requirement that the hostname in the connection string must match the exact string printed on the cloud provider’s certificate, which is standard practice when using internal proxy routers or custom DNS aliases.