Some people have identified that Oracle Enterprise Manager connections have been causing these error messages. The error is generated with OJDBC versions 6 and 7, but not with the OJDBC version 8 and fat client. Since 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. ojdbc7.jar ConnectDB server:port:db user password I could indeed reproduce the TNS error by supplying wrong credentials to the following Java program: import Ĭlass.forName("") Ĭonnection = " + argv, argv, argv) This function handles authentication – I already saw it when analyzing an RMAN authentication problem. The error was generated in the Oracle C function ksesecl0, whose description is “kernel service error security”, see Frits Hoogland’s orafun. ORA-12599: TNS:cryptographic checksum mismatch } dtrace -s alertlog_writes.d '"alert_DB"' Once more, I used the technique for enriching the log file with call stacks to get an idea about what could have led to the problem: syscall::write:entry The process was short-lived and impossible to observe. Since I couldn’t reproduce the error just by connecting to a database, I gathered more information about the process with the following configuration: alter system set events '12599 trace name errorstack forever, level 3' Īn additional trace file for the dedicated server process was generated: Errors in file /u00/oracle/orabase/diag/rdbms/db_site1/DB/trace/DB_ora_c:īesides the process ID, the trace file didn’t contain any other useful information. The error could be traced down to JDBC connections by correlating the timestamp with listener log. TNS-12599: TNS:cryptographic checksum mismatch TCP/IP NT Protocol Adapter for Solaris: Version 19.0.0.0.0 - Production Oracle Bequeath NT Protocol Adapter for Solaris: Version 19.0.0.0.0 - Production TNS for Solaris: Version 19.0.0.0.0 - Production The error message doesn’t contain much useful information despite its verbosity: NI cryptographic checksum mismatch error: 12599. ![]() ![]() In this article I’ll explain the circumstances under which this error occur and how to get rid of it without compromising security. ![]() After all, you wouldn’t remove an ugly lock from your door just to improve the esthethics, would you? But that would severely compromise the security – “required” is the only value that really enforces encryption. SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)Ī plethora of articles on Internet suggests downgrading encryption to a less strict mode to get rid of the error messages. We use the following configuration: SQLNET.CRYPTO_CHECKSUM_SERVER = required The alert logs of some of our databases have been cluttered with the “TNS-12599: TNS:cryptographic checksum mismatch” error messages.
0 Comments
Leave a Reply. |