There are a few bits in OEM using older jdbc or sqlnet connections that do not
support the later encryption types , so the workaround you did is correct .
Apparently just upgrading to a later version breaks other things , so a true
patch has been long overdue . Oem 13.4 and 13.5 I know are affected , there
may be other versions as well.
Sent from my Atari 2600
On Oct 31, 2022, at 12:46 PM, Lyall Barbour <lyallbarbour@xxxxxxxxxxxxxxx>
wrote:
We did this, Ill look back at my notes later but two things come to mind.
1) there a config file on the oem server that needs or (or less) encryption
options in it. Xml file maybe?
2) the Agent on the OEM server needs to be secured with the new encryption.
Lyall
--
Sent from my Android phone with mail.com Mail. Please excuse my brevity.
On 10/31/22, 12:35 PM niall.litchfield@xxxxxxxxx wrote:-- //www.freelists.org/webpage/oracle-l
I'm pretty sure that the strongest checksum-type OEM supports is SHA256,
hence my suggestion to check with support, and a pointer at the notes that
describe allowable options.
On Mon, Oct 31, 2022 at 4:21 PM Ilmar Kerm <ilmar.kerm@xxxxxxxxx> wrote:
I think SHA512 was added in 12.2 (including the driver).
Try adding some older checksum algorithms also, so connection would work
with older driver also:
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA512, SHA256, SHA1)
On Mon, Oct 31, 2022 at 4:38 PM Scott Canaan <srcdco@xxxxxxx> wrote:
All of the databases are on Oracle 12.1 or later, most are 19c.
I did get it to work by setting the values in the oms config file,
bouncing the oms, and changing the crypto_checksum_client/server from
REQUIRED to ACCEPTED. I don’t know why I had to do that last part, but
the JDBC would not connect with it set to REQUIRED. The oms came up and
it does connect to all of the databases now.
At this point, I’m just going to leave it that way. The first thing
Oracle support said to do was to back out the sqlnet.ora changes. I
didn’t want to do that, so this is the compromise.
Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco@xxxxxxx | c: (585) 339-8659
CONFIDENTIALITY NOTE: The information transmitted, including attachments,
is intended only for the person(s) or entity to which it is addressed and
may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and destroy any copies of this information.
From: niall.litchfield@xxxxxxxxx <niall.litchfield@xxxxxxxxx>
Sent: Monday, October 31, 2022 11:34 AM
To: Scott Canaan <srcdco@xxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Cloud Control Issue
Hi Scott
I think you'll need to follow both
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2376633.1 for ;
the repository and
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2782968.1 for ;
the targets. I'd also check that SHA512 is supported.
On Mon, Oct 31, 2022 at 1:56 PM Scott Canaan <srcdco@xxxxxxx> wrote:
In trying to follow the request from Oracle support to reproduce the error
with tracing turned on, I discovered that the oms won’t even start. The
log shows:
java.sql.SQLException: Oracle Error ORA-12650
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:855)
at
oracle.jdbc.driver.PhysicalConnection.connect(PhysicalConnection.java:924)
at
oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:58)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:760)
at
oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:435)
at
oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:306)
at
oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:221)
at
oracle.jdbc.pool.OracleConnectionPoolDataSource.getPhysicalConnection(OracleConnectionPoolDataSource.java:149)
at
oracle.jdbc.pool.OracleConnectionPoolDataSource.getPooledConnection(OracleConnectionPoolDataSource.java:92)
at
oracle.jdbc.pool.OracleImplicitConnectionCache.makeCacheConnection(OracleImplicitConnectionCache.java:1745)
at
oracle.jdbc.pool.OracleImplicitConnectionCache.makeOneConnection(OracleImplicitConnectionCache.java:628)
at
oracle.jdbc.pool.OracleImplicitConnectionCache.getCacheConnection(OracleImplicitConnectionCache.java:577)
at
oracle.jdbc.pool.OracleImplicitConnectionCache.getConnection(OracleImplicitConnectionCache.java:454)
at
oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:542)
at
oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:510)
at
oracle.sysman.emSDK.core.util.jdbc.ConnectionCache._getConnection(ConnectionCache.java:433)
at
oracle.sysman.emSDK.core.util.jdbc.ConnectionCache._getConnection(ConnectionCache.java:394)
at
oracle.sysman.emSDK.core.util.jdbc.ConnectionCache.getUnwrappedConnection(ConnectionCache.java:814)
at
oracle.sysman.emSDK.svc.conn.FGAConnectionCache.getFGAConnection(FGAConnectionCache.java:212)
at
oracle.sysman.emSDK.svc.conn.ConnectionService.getPrivateConnection(ConnectionService.java:1279)
at
oracle.sysman.emSDK.svc.conn.ConnectionService.getPrivateConnection(ConnectionService.java:1294)
at
oracle.sysman.core.pbs.gcloader.PostloadJobExecutor.doWork(PostloadJobExecutor.java:327)
at
oracle.sysman.core.pbs.gcloader.PostloadJobExecutor.executeCommand(PostloadJobExecutor.java:177)
at
oracle.sysman.core.pbs.gcloader.LoaderjobWorker.doWork(LoaderjobWorker.java:285)
at oracle.sysman.core.common.workmanager.Work.call(Work.java:274)
at oracle.sysman.core.common.workmanager.Work.call(Work.java:50)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
There are many of these. I’m guessing there’s a configuration file
somewhere that needs to be adjusted to accommodate the new sqlnet.ora
settings, but I have no idea where it is.
Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco@xxxxxxx | c: (585) 339-8659
CONFIDENTIALITY NOTE: The information transmitted, including attachments,
is intended only for the person(s) or entity to which it is addressed and
may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and destroy any copies of this information.
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On
Behalf Of Scott Canaan
Sent: Monday, October 31, 2022 9:26 AM
To: 'oracle-l@xxxxxxxxxxxxx' <oracle-l@xxxxxxxxxxxxx>
Subject: Cloud Control Issue
On Saturday, we updated all the sqlnet.ora files on all the database
servers to be more secure. The changes were to make both encryption and
the crypto-checksum required and to set the crypto-checksum value to
SHA512 only. This was also done on the cloud control server. Now, cloud
control can’t connect to any database. It gets an ORA-12650: No common
encryption or data integrity algorithm.
We are on cloud control 13.5 on Red Hat 8 and it is patched through
August, 2022. I found an old metalink document about a bug, 28527508, but
when I try to apply it, I get an error saying that we aren’t at the
correct version. I expect it’s too old as it is from 2018.
Any ideas on how to fix this? I’m trying to open an SR, but they want a
ton of logs and files and I don’t really have the time to go back and
forth with them.
Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco@xxxxxxx | c: (585) 339-8659
CONFIDENTIALITY NOTE: The information transmitted, including attachments,
is intended only for the person(s) or entity to which it is addressed and
may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and destroy any copies of this information.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
Ilmar Kerm
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
