ODP.NET connection to Oracle 19 via Windows 2022 Server
asdfafasd123 opened this issue · 8 comments
Hello,
I am running the following C# code successfully from my laptop:
class Program { static void Main() { string connectionString = "User Id=xx;Password=xx;Data Source = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = xxx)(PORT = 2484))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = xxx)))"; OracleConfiguration.SqlNetWalletOverride = true; OracleConfiguration.WalletLocation= "C:\\wallet"; OracleConfiguration.TraceLevel = 7; OracleConfiguration.TraceFileLocation = "C:\\LOGS"; try { using (var connection = new OracleConnection(connectionString)) { connection.Open(); Console.WriteLine("Connected successfully to TCPS!"); } } catch (Exception ex) { Console.WriteLine($"Error: {ex.Message}"); Console.WriteLine($"Stack Trace: {ex.StackTrace}"); } } }
However when attempting to run the same code on a Windows 2022 Server I am receiving the following error in the trace:
2025-01-17 11:16:09.194245 TID:5 (PRI) (EXT) OracleException.ctor()
2025-01-17 11:16:09.205487 TID:5 (PRI) (SVC) (ERR) (CID1) OracleException.HandleError() from OracleConnectionImpl.Connect()(txnid=n/a) OracleInternal.Network.NetworkException (0x80004005): ORA-50201: Oracle Communication: Failed to connect to server or failed to parse connect string
---> OracleInternal.Network.NetworkException (0x80004005): ORA-00542: SSL Handshake failed
https://docs.oracle.com/error-help/db/ora-00542/
---> System.Security.Authentication.AuthenticationException: Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'.
---> System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.
--- End of inner exception stack trace ---
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
at System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions)
at OracleInternal.Network.TcpsTransportAdapter.Negotiate(ConnectionOption conOption)
at OracleInternal.Network.TcpsTransportAdapter.Negotiate(ConnectionOption conOption)
at OracleInternal.Network.TcpsTransportAdapter.Renegotiate(ConnectionOption conOption)
at OracleInternal.Network.OracleCommunication.SendConnectPacketAndProcessResponse(AddressResolution addrRes, Boolean bAsync)
at OracleInternal.Network.OracleCommunication.ConnectViaCO(ConnectionOption connOption, AddressResolution addrRes, Boolean bAsync)
at OracleInternal.Network.OracleCommunication.DoConnect(String tnsDescriptor, Boolean bAsync)
at OracleInternal.Network.OracleCommunication.Connect(String tnsDescriptor, Boolean doNAHandshake, String IName, ConnectionOption CO, Boolean bAsync)
at OracleInternal.ServiceObjects.OracleConnectionImpl.Connect(ConnectionString cs, Boolean bOpenEndUserSession, OracleConnection connRefForCriteria, String instanceName, Boolean bAsync)
2025-01-17 11:16:09.205540 TID:5 (PRI) (EXT) (CID1) OracleException.HandleError() from OracleConnectionImpl.Connect()
I can verify that I can connect from the server using sqlplus and that there are no issues. Can anyone please point me in what I am missing?
Thank you!
Also, other things that I have done to try to debug this:
- Test-NetConnextion over port 2484 -> Successful
- TNSping over TCPS/2484 -> Successful
- SQLPlus connection over TCPS/2484 -> Successful
- Change the connection string back to TCP/1521 ->Successful
If anyone has any guidance why this works from my local machine and not from a Windows Server 2022 hosted on Azure please let me know.
do you have an sqlnet.ora file on the windows 2022 work directory ?
I have tried both with it and without it. Same error.
When you say the work directory you mean the TNS_ADMIN directory I assume?
The TLS setup is most likely misconfigured. It's hard to debug without knowing how you've configured TLS. If you would like Oracle to take a look, you can send your level 7 trace file to dotnet_us(at)oracle.com.
The trace file will tell us what part of the connection negotiation process failed and usually why.
The trace is on the way. I emailed it a minute ago.
From the trace, your connection succeeded in the SSL handshake to the listener but failed in the handshake to the dedicated server. The trace is reporting the wallet you're using doesn't have a private key in the certificate. If the DB server requires two-way SSL, that could be the reason for the failure.
My team has also seen these handshake failure types occur when there is a cipher suite mismatch. Can you check what cipher suites the DB server allows? For a connection to be successful, the client side should have at least one common cipher suite enabled.
I'm glad you were able to find a solution.