Wallets for encrypting database connections? No, not any more…!
When you want to encrypt your client connections to the database, one used to create Oracle Wallets. With an Oracle wallet you run ‘SQL*Net over an SSL connection’. Your tcp connection will be transformed to tcps.
This is not necessary if you easily want to encrypt all your connections to the database. You do not use tcps, you still use tcp, but you encrypt SQL*Net traffic, which is a different approach.
If you use “Native Oracle Net Services encryption and integrity”, you can encrypt all SQL*Net traffic from a client, for all connections to a database and it’s even also configurable per WebLogic Connection Pool. Continue reading
&tldr; in sqlnet.ora :
# the minimum allowed client version to connect to the databases from this home
# set this to accept lower versions of the autentication protocol
# if you have a database link to a lower version of an Oracle
# set this to that lower version to talk the same authentication protocol
# 12a => 188.8.131.52
# 12a for Oracle Database 12c release 184.108.40.206 or later
# 12 for the critical patch updates CPUOct2012 and later Oracle Database 11g
# 11 for Oracle Database 11g
# 10 for Oracle Database 10g
# 9 for Oracle9i
# 8 for Oracle8i
Ah, an old client is trying to connect to Oracle 12c (presumably)… ;)
Also “ORA-03134: Connections to this server version are no longer supported” can occur.
This actually implies that the authentication protocols use between client and server do not match. In Oracle 12c, the authentication protocol uses SHA-2 encryption algorithm by default, where older clients use SHA-1. So when an older client is used with defaults, the server will not accept the connection.
The best option would be upgrading the client, but when older dll’s are used (like ojdbc14.jar and you can not change this), this is a problem. The database instance can be told to accept older clients and use the older SHA-1 encryption algorithm.
The Easy Connect Naming Method allows you to connect to a database service without having to configure Net Service Names.
The most found example on internet is the one with typing the password at the command prompt when starting sqlplus:
$> sqlplus system/manager@db_machine:1521/db_servicename
However, this means that the password will be stored in you history of commands (linux). This is not really secure… but sqlplus does not accept it when no password is supplied when using easy connect.
If you want to login with easy connect without typing the password on the command line, you have two options: Continue reading
When having multiple Oracle homes on Windows, how is decided which Oracle home (in the registry) is used by an Oracle binary? Which NLS_LANG or TNS_ADMIN setting from the registry is used?
The answer is binary, path, oracle.key, registry… and which for Windows. Continue reading