Oracle ORA-12599 Error: Causes and Solutions Complete Guide

ORA-12599: TNS Cryptographic Checksum Mismatch — Causes, Fixes & Prevention

ORA-12599 is an Oracle Net Services (TNS) error that occurs when the cryptographic checksum computed by the sender does not match the value recalculated by the receiver during a database connection attempt. This mismatch prevents the client from establishing a session with the Oracle database, effectively blocking all application connectivity. It is most commonly triggered by mismatched sqlnet.ora configurations, version incompatibilities between Oracle client and server, or packet manipulation by intermediate network devices.

---

Top 3 Causes

1. Mismatched sqlnet.ora Checksum Settings

The most common cause is a mismatch between the SQLNET.CRYPTO_CHECKSUM_SERVER and SQLNET.CRYPTO_CHECKSUM_CLIENT parameters — or their associated algorithm lists. If the server is set to REQUIRED but the client is set to REJECTED, the connection is immediately refused.

-- Check current session-level network service banners to confirm
-- which checksum algorithm (if any) is being negotiated
SELECT SID,
       SERIAL#,
       USERNAME,
       NETWORK_SERVICE_BANNER
FROM   V$SESSION_CONNECT_INFO
WHERE  NETWORK_SERVICE_BANNER LIKE '%Checksum%'
ORDER BY SID;

-- Check database-level parameters related to security/crypto
SELECT NAME, VALUE
FROM   V$PARAMETER
WHERE  NAME LIKE '%crypto%'
    OR NAME LIKE '%checksum%'
ORDER BY NAME;

Fix: Align both sqlnet.ora files so the algorithm types overlap and the enforcement levels are compatible (e.g., both set to ACCEPTED or REQUESTED).

-- Recommended server-side sqlnet.ora
-- SQLNET.CRYPTO_CHECKSUM_SERVER   = ACCEPTED
-- SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA1, MD5)

-- Recommended client-side sqlnet.ora
-- SQLNET.CRYPTO_CHECKSUM_CLIENT   = REQUESTED
-- SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA256, SHA1, MD5)

---

2. Oracle Client / Server Version Incompatibility

Older Oracle clients (pre-12c) may not support modern checksum algorithms such as SHA-256. If the server enforces SHA-256 or higher as REQUIRED, the handshake fails with ORA-12599.

-- Identify the Oracle version running on the server
SELECT BANNER FROM V$VERSION;

-- Review failed login attempts with return code 12599
-- (requires Unified Auditing or Standard Auditing to be enabled)
SELECT OS_USERNAME,
       USERNAME,
       USERHOST,
       TIMESTAMP,
       RETURNCODE
FROM   DBA_AUDIT_SESSION
WHERE  RETURNCODE = 12599
ORDER BY TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

Fix: Upgrade the Oracle client to a version that supports the algorithms required by the server, or temporarily add older algorithms (e.g., SHA1, MD5) to the server's accepted list to maintain backward compatibility while clients are being upgraded.

---

3. Packet Manipulation by Network Devices

Firewalls, load balancers, SSL offloaders, or Deep Packet Inspection (DPI) devices can alter TNS packet content in transit. When the receiver recalculates the checksum, it no longer matches the original, triggering ORA-12599. This scenario typically appears only in production environments where additional network appliances exist.

-- Identify sessions by machine/host to spot patterns
-- (e.g., only certain subnets or hosts are failing)
SELECT S.SID,
       S.SERIAL#,
       S.USERNAME,
       S.MACHINE,
       S.OSUSER,
       S.STATUS,
       CI.NETWORK_SERVICE_BANNER
FROM   V$SESSION S
JOIN   V$SESSION_CONNECT_INFO CI
    ON S.SID = CI.SID
WHERE  S.USERNAME IS NOT NULL
ORDER BY S.LOGON_TIME DESC;

Fix: Work with your network team to identify and whitelist Oracle TNS traffic so it bypasses DPI or packet inspection. As a temporary diagnostic step, you can disable checksum on the server side to isolate the cause — but re-enable it immediately after testing.

-- TEMPORARY DIAGNOSTIC ONLY — requires security team approval
-- Set in server sqlnet.ora:
-- SQLNET.CRYPTO_CHECKSUM_SERVER = NONE
-- Test connectivity, then revert to original setting immediately

---

Quick Fix Summary

Scenario	Action
sqlnet.ora mismatch	Align algorithm lists and enforcement levels on both sides
Old client version	Upgrade client or add legacy algorithms to server's accepted list
Network device interference	Bypass DPI/inspection for TNS traffic; temporarily disable checksum to confirm
Emergency recovery	Set both sides to ACCEPTED with a shared algorithm (e.g., SHA256)

---

Prevention Tips

1. Treat sqlnet.ora as a paired configuration artifact.
Whenever you update the server-side sqlnet.ora, always update the client-side file at the same time. Store both files in version control (Git) and include a connectivity smoke test in your deployment pipeline to catch mismatches before they hit production.

2. Set up automated monitoring for ORA-12599 in alert and audit logs.
Schedule a lightweight monitoring job using DBMS_SCHEDULER that queries DBA_AUDIT_SESSION for return code 12599 and sends an alert if the count exceeds a threshold. This helps you catch both misconfiguration and potential security threats early.

-- Schedule this as a DBMS_SCHEDULER job for proactive monitoring
SELECT USERHOST,
       USERNAME,
       COUNT(*)        AS FAIL_COUNT,
       MAX(TIMESTAMP)  AS LAST_ATTEMPT
FROM   DBA_AUDIT_SESSION
WHERE  RETURNCODE = 12599
  AND  TIMESTAMP  >= SYSDATE - 1/24  -- last 1 hour
GROUP  BY USERHOST, USERNAME
HAVING COUNT(*) >= 5
ORDER  BY FAIL_COUNT DESC;

---

Related Oracle Errors

• ORA-12650 — No common encryption or checksum algorithm; often appears alongside ORA-12599.
• ORA-12592 — TNS packet writer failure; indicates low-level packet corruption on the network.
• ORA-12651 — Encryption or data integrity algorithm failed to initialize; related to Advanced Security Option issues.
• ORA-28860 — Fatal SSL error; occurs in TCPS environments and may co-occur with checksum failures.

---

📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.