![]() ![]() 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. |