By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,028 Members | 1,825 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,028 IT Pros & Developers. It's quick & easy.

Oracle ODBC error with ENCRYPTION

P: n/a
We are trying to connect to 3 different Oracle databases using MS
Access as the front-end and ODBC as the connection. The problem that
we are having is that 1 of the databases requires a CRYPTO_SEED. With
the sqlnet.ora file configured for the encryption, the other 2
databases won't connect and vise versa. Is there a way to make the
connections use encryption when required and not use it when not
required.

We are using 9i client version 9.2 and it's ODBC driver (also tried
getting the latest driver from Oracle on one machine).

NOTE: We have 3 machines set up that work, but the main difference
with those machines is that they use 9i version 9.01. I don't want to
have to use that version if at all possible. If that's the problem,
then I will have this problem again in the furture. I don't want to
just postpone the problem. All machines (including the ones that
work) use the same sqlnet.ora file.

sqlnet.ora:
SQLNET.AUTHENTICATION_SERVICES = (BEQ,NTS,NONE)
NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME, ONAMES)
SQLNET.ENCRYPTION_CLIENT = accepted
SQLNET.ENCRYPTION_TYPES_CLIENT = (DES40, RC4_56)
SQLNET.CRYPTO_SEED = {left out here}
SQLNET.CRYPTO_CHECKSUM_CLIENT = accepted
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (MD5)

Does any of the experts have any idea. I am definately not an expert
when it comes to Oracle.

Thanks in advance
Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
In article <69*************************@posting.google.com> , Cliff says...

We are trying to connect to 3 different Oracle databases using MS
Access as the front-end and ODBC as the connection. The problem that
we are having is that 1 of the databases requires a CRYPTO_SEED. With
the sqlnet.ora file configured for the encryption, the other 2
databases won't connect and vise versa. Is there a way to make the
connections use encryption when required and not use it when not
required.

We are using 9i client version 9.2 and it's ODBC driver (also tried
getting the latest driver from Oracle on one machine).

NOTE: We have 3 machines set up that work, but the main difference
with those machines is that they use 9i version 9.01. I don't want to
have to use that version if at all possible. If that's the problem,
then I will have this problem again in the furture. I don't want to
just postpone the problem. All machines (including the ones that
work) use the same sqlnet.ora file.

sqlnet.ora:
SQLNET.AUTHENTICATION_SERVICES = (BEQ,NTS,NONE)
NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME, ONAMES)
SQLNET.ENCRYPTION_CLIENT = accepted
SQLNET.ENCRYPTION_TYPES_CLIENT = (DES40, RC4_56)
SQLNET.CRYPTO_SEED = {left out here}
SQLNET.CRYPTO_CHECKSUM_CLIENT = accepted
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (MD5)

Does any of the experts have any idea. I am definately not an expert
when it comes to Oracle.

Thanks in advance


The problem is that if SQLNET.ENCRYPTION_CLIENT is set to "accepted" on both
machines and encryption is specified, then SQL*Net (really ASO) will try to
encrypt the connection. Since the SQLNET.CRYPTO_SEED parameter is required for
encryption, the connection will fail without it.

I'm unclear as to whether all three databases have encryption enabled. If they
do, I would just set the crypto_seed parameter to some random string of 70
characters (get a cat, they're good at generating them :-).

If one of the databases does not have encryption, comment out the value of
SQLNET.ENCRYPTION_CLIENT parameter for that database. That will disable the use
of encryption for that database.

Rick

P.S. I would change DES40 to something stronger like DES (or 3DES, if
available). While DES40 will protect the connection, DES or Triple DES is
better. I would do the same with RC4_56. If it's available, I would use RC4_128
or RC4_256.

P.S. To respond by mail, please reverse the "elcaro".
Rick Wessman
Oracle Corporation
The opinions expressed above are mine and do not necessarily reflect
those of Oracle Corporation.

Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.