The alert logs of some of our databases have been cluttered with the “TNS-12599: TNS:cryptographic checksum mismatch” error messages.<\/p>\n
We use the following configuration:<\/p>\n
SQLNET.CRYPTO_CHECKSUM_SERVER = required\nSQLNET.ENCRYPTION_SERVER = required\nSQLNET.ENCRYPTION_TYPES_SERVER = (AES256)<\/code><\/pre>\nA plethora of articles on Internet suggests downgrading encryption to a less strict mode to get rid of the error messages. But that would severely compromise the security – “required” is the only value that really enforces encryption. After all, you wouldn’t remove an ugly lock from your door just to improve the esthethics, would you?<\/p>\n
In this article I’ll explain the circumstances under which this error occur and how to get rid of it without compromising security.<\/p>\n
The error message doesn’t contain much useful information despite its verbosity:<\/p>\n
NI cryptographic checksum mismatch error: 12599.\n\n VERSION INFORMATION:\n TNS for Solaris: Version 19.0.0.0.0 - Production\n Oracle Bequeath NT Protocol Adapter for Solaris: Version 19.0.0.0.0 - Production\n TCP\/IP NT Protocol Adapter for Solaris: Version 19.0.0.0.0 - Production\n Version 19.9.0.0.0\n Time: 01-MAY-2021 13:01:05\n Tracing not turned on.\n Tns error struct:\n ns main err code: 12599\n\nTNS-12599: TNS:cryptographic checksum mismatch\n ns secondary err code: 12656\n nt main err code: 0\n nt secondary err code: 0\n nt OS err code: 0<\/code><\/pre>\nThe error could be traced down to JDBC connections by correlating the timestamp with listener log.<\/p>\n
Since I couldn’t reproduce the error just by connecting to a database, I gathered more information about the process with the following configuration:<\/p>\n
alter system set events '12599 trace name errorstack forever, level 3';<\/code><\/pre>\nAn additional trace file for the dedicated server process was generated:<\/p>\n
Errors in file \/u00\/oracle\/orabase\/diag\/rdbms\/db_site1\/DB\/trace\/DB_ora_20019.trc:<\/code><\/pre>\nBesides the process ID, the trace file didn’t contain any other useful information. The process was short-lived and impossible to observe.<\/p>\n
Once more, I used the technique for enriching the log file with call stacks<\/a> to get an idea about what could have led to the problem:<\/p>\nsyscall::write:entry\n\/ strstr( fds[arg0].fi_pathname, $1 ) != 0 \/\n{\n trace(copyinstr(arg1));\n ustack(100);\n}<\/code><\/pre>\ndtrace -s alertlog_writes.d '\"alert_DB\"'\n\nORA-12599: TNS:cryptographic checksum mismatch\n\nlibc.so.1`__write+0xa\noracle`sdbgrfuwf_write_file+0x64\noracle`sdbgrfwf_write_file+0x3c\noracle`dbglWriteTextOnly+0x65c\noracle`dbglWriteLogCommon+0x2cf\noracle`dbgrlWriteAlertDetail+0x25a\noracle`dbgrlWriteAlertText+0x26\noracle`dbkrlPril+0x245\noracle`kgedes+0xb9\noracle`dbkedDefDump+0x6fd\noracle`ksedmp+0x2b8\noracle`dbkdaKsdActDriver+0xd03\noracle`dbgdaExecuteAction+0x178\noracle`dbgdaRunAction+0x29b\noracle`dbgdRunActions+0x90\noracle`dbgdProcessEventActions+0x124\noracle`dbgdChkEventKgErr+0x925\noracle`dbkdChkEventRdbmsErr+0x4a\noracle`ksfpec+0x6f\noracle`dbgePostErrorKGE+0x495\noracle`dbkePostKGE_kgsf+0x3b\noracle`kgeade+0x447\noracle`kgeselv+0x67\noracle`ksesecl0<\/span>+0xb7\noracle`opiino+0xf83\noracle`opiodr+0x439\noracle`opidrv+0x33f\noracle`sou2o+0x97\noracle`opimai_real+0x121\noracle`ssthrdmain+0x26b\noracle`main+0xa9\noracle`0x77e2b14<\/code><\/pre>\nThe error was generated in the Oracle C function ksesecl0<\/span>, whose description is “kernel service error security”, see Frits Hoogland’s orafun<\/a>.<\/p>\nThis function handles authentication – I already saw it when analyzing an RMAN authentication problem <\/a>.<\/p>\nI could indeed reproduce the TNS error by supplying wrong credentials to the following Java program:<\/p>\n
import java.sql.DriverManager;\nimport java.sql.Connection;\nimport java.sql.SQLException;\n\npublic class ConnectDB {\n public static void main(String[] argv) {\n Connection connection = null ;\n try {\n Class.forName(\"oracle.jdbc.driver.OracleDriver\");\n } catch (ClassNotFoundException e) {\n e.printStackTrace();\n return;\n }\n\n try {\n connection = DriverManager.getConnection(\n \"jdbc:oracle:thin:@ \" + argv[0], argv[1], argv[2]);\n } catch (SQLException e) {\n e.printStackTrace();\n return;\n }\n }\n}<\/code><\/pre>\nCompile it with:<\/p>\n
javac ConnectDB.java<\/code><\/pre>\nRun it as follows:<\/p>\n
java -cp .:.\/ojdbc7.jar ConnectDB server:port:db user password<\/code><\/pre>\nSince the error doesn’t appear after a successful connection, we can conclude that the code that handles exception after a login error doesn’t implement the checksumming correctly.<\/p>\n
The error is generated with OJDBC versions 6 and 7, but not with the OJDBC version 8 and fat client.<\/p>\n
Some people have identified that Oracle Enterprise Manager connections have been causing these error messages. That’s because OEM 13.4 sadly uses the version 7 even though the deployed java version is 8 :<\/p>\n
ps -ef | grep agent | grep java\noracle 3224 2765 0 Mar 02 ? 4843:07 \/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/jdk\/bin\/java -Xmx128M -XX:MaxMetaspaceSize=224M -server -d64 -Djava.security.egd=file:\/\/\/dev\/.\/urandom -Dsun.lang.ClassLoader.allowArraySyntax=true -XX:-DoEscapeAnalysis -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCompressedOops -XX:-UseLWPSynchronization -Dsun.security.pkcs11.enable-solaris=false -Dwatchdog.pid=2765 -cp \/oracle\/product\/agent13c\/agent_13.4.0.0.0\/jdbc\/lib\/ojdbc7.jar<\/span>:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/ucp\/lib\/ucp.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/jsch-0.1.54.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/com.oracle.http_client.http_client.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/oracle.xdk\/xmlparserv2.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/oracle.dms\/dms.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/oracle.odl\/ojdl.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/modules\/oracle.odl\/ojdl2.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/lib\/optic.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/sysman\/jlib\/log4j-core.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/jlib\/gcagent_core.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/sysman\/jlib\/emagentSDK-intg.jar:\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/sysman\/jlib\/emagentSDK.jar oracle.sysman.gcagent.tmmain.TMMain<\/code><\/pre>\n\/oracle\/product\/agent13c\/agent_13.4.0.0.0\/oracle_common\/jdk\/bin\/java -version\njava version \"1.8.0_231\"<\/span>\nJava(TM) SE Runtime Environment (build 1.8.0_231-b34)\nJava HotSpot(TM) 64-Bit Server VM (build 25.231-b34, mixed mode)<\/code><\/pre>\nIf your applications can’t upgrade to OJDBC 8, you can redirect these error messages to the SQLNet server log with the following configuration:<\/p>\n
DIAG_ADR_ENABLED=off\nLOG_FILE_SERVER=server.log\nLOG_DIRECTORY_SERVER=\/oracle\/network\/log<\/code><\/pre>\nSummary<\/h1>\n
In summary, OJDBC versions below 8 don’t handle encryption correctly after a log on error. As a consequence, the TNS-12599 error message gets written in the alert log file. This error message is normally of no interest to DBAs – the client received the error message for the failed log on and should respond to it. Massive failed logons from JDBC clients can clutter the alert log.<\/p>\n
Therefore, instruct the applications to upgrade to OJDBC 8. If not feasible, you can redirect those message to tne SQLNet server log.<\/p>\n","protected":false},"excerpt":{"rendered":"
Older JDBC versions causing TNS-12599: TNS:cryptographic checksum mismatch Continue Reading