Am using WebSphere 9.0.5.10 and trying to connect DB2 database over SSL port.
I tried to retrieve the certificate from DB2 database by using the below procedure.
Import the database server certificate.
1.Open the WebSphere Application Server administrative console.
Security > SSL certificate and key management > Key stores and certificates > {NodeDefKeystore}
Signer certificates > Retrieve from port.
Clicked Retrieve from port.
Enter the host name and security port of the database server.
Type an alias name for the certificate.
Click Retrieve signer information.
Click OK to save the configuration.
2.Configure the data source to support SSL connections.
Select Resources > JDBC > Data sources.
Select WebSphere Commerce database DataSource demo in the data source list, where database can be either DB2 or Oracle.
Update the port number in the Common and required data source properties section. Enter the value of the security port that you set in the database server.
Clicked Apply.
In the Additional Properties section, select Custom properties.
Clicked New
Enter sslConnection in the Name field, and enter true in the Value field.
Click OK to save the configurations.
Post service restart, tried to check the database connection and got below error.
Someone please help to resolve the issue.
Error: The test connection operation failed for data source on server nodeagent at node with the following exception: java.sql.SQLException: [jcc][t4][2030][11211][4.29.24] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - socketInputStream.read (-1). Message: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target. ERRORCODE=-4499, SQLSTATE=08001 DSRA0010E: SQL State = 08001, Error Code = -4,499. View JVM logs for further details.
The Test Connection function makes a best attempt at connecting, but some security requirements are not supported by this, since Test Connection is not an equivalent application.
Test Connection does not have the same quality of function available as an application, hence, an application in this case is the best method to test any database connections.
Another document that is well worth checking is:
WebSphere Application Server Data Source driver connection over SSL with Database server
https://community.ibm.com/community/user/wasdevops/blogs/ajit-jariwala/2021/10/06/websphere-application-server-data-source-driver-c
Otherwise it's more of a DB2 JDBC Driver issue with the error -4499
Perhaps, also test the very latest JDBC Driver 4.32.28
https://www.ibm.com/support/pages/db2-jdbc-driver-versions-and-downloads
Hope it helps!
Dave
Related
I am trying to load data from source to target in informatica but I am getting error when I start workflow:-
workflow
error1:-
Severity Timestamp Node Thread Message Code Message
INFO 01-09-2022 6.12.46 PM node01 MAPPING DBG_21349 No load constraints for Target [target_info]. It does not reference any primary table from the same active source or transaction generator.
error2-
Severity Timestamp Node Thread Message Code Message
ERROR 01-09-2022 6.12.46 PM node01 PRE-SESS CMN_1022 Database driver error...
CMN_1022 [
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Database driver error...
Function Name : Connect
Database driver error...
Function Name : Connect
Database Error: Failed to connect to database using user [dbc] and connection string [].]
I am not able to understand , its a ODBC connection error or mapping level issue.
please help me to solve this.
I am sharing screenshot of the error log also.
error log
You need to setup ODBC connection information. As per session log, i do not see proper connection info set for target. Session failed when it is trying to connect to target DB.
To set ODBC, you need to first setup odbc.ini file located at $INFA_HOME/ODBC7.1/odbc.ini. You need to enter details like host/port/db name in proper format. Name the connection to mytarget(or whatever you prefer).
how to set this up can be found in this link -
Informatica: wrong odbc.ini file referred by Workflow mappings
Create new informatica connection of type ODBC(name it as myconnection). Supply user/password and mytarget as connection string.
in the session, set this target to this connection object myconnection.
Eclipse Version: Neon.3 Release (4.6.3)
On New Database Connection Profile/Wizard, I select Oracle as Database Type add ojdbc 8 jar and enter requested details for Oracle instance running on remote server.
I enter server, port and service values as I enter in SQL Developer (where I am able to connect), but connection test never succeed from Eclipse.
Once values are entered it constructs JDBC URL (which is not editable) in below format:
jdbc:oracle:thin:#server:port:service
Error message:
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
Though I wanted to directly provide jdbc URL "Connection URL" field is not editable.
After some more digging found it in one of Eclipse bug reports. Thanks to Mike Hatherly for workaround, reference: https://bugs.eclipse.org/bugs/show_bug.cgi?id=382063#c3
Work around provided by Mike Hatherly:
"I have found a workaround. If you export the Database connection details, you can then manually edit the property org.eclipse.datatools.connectivity.db.URL to include the missing '/'s, then re-import and overwrite the current connection. Doing this however shows the connection properties in Eclipse as missing values, although the connection works correctly."
So before exporting you would 've saved connection profile with password and everything and Export un-encrypted. And the correct URL format when using ServiceName: jdbc:oracle:thin:#//server:port/ServiceName
I'm trying to run liquibase update command using
liquibase --driver="com.ibm.db2.jcc.DB2Driver" --changeLogFile="masterchangelog.xml " --url="jdbc:db2://localhost:60001/SMDINTDB:retrieveMessageFromServerOnGetMessage=true;sslConnection=true;" --username="" --password="" --classpath=/home/db2inst1/sqllib/java/db2jcc4.jar validate
But I'm getting following error. Can anyone help me how to resolve this issue? How I can specify the location of certs ?
Unexpected error running Liquibase: com.ibm.db2.jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][2030][11211][4.26.14] A communication error occurred during operations on the connection's underlying socket, socket input stream,
or socket output stream. Error location: Reply.fill() - socketInputStream.read (-1). Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. ERRORCODE=-4499, SQLSTATE=08001
Several pre-requisites exist for on-premises Db2-LUW SSL connectivity with jdbc.
liquibase works correctly with SSL connections to on-premises Db2-LUW, if all the prerequisite configuration completed successfully. Here are some tips.
the target Db2-LUW instance has to be already configured for SSL as per IBM Db2 documentation here. If you are using a cloud based Db2 service from IBM then this is already done for you, although you may need to use the IBM supplied root cert on the client side.
your client side JRE needs to be configured per IBM's Db2-LUW documentation here. I use the IBM JRE (as supplied with the Db2-LUW server) for liquibase.
for on-premises Db2-LUW your client side needs the java keystore created, and the server's certificate imported into it (keytool -importcert -file /your/path/to/server_certificate ... ).
for your specific error, for on-premises Db2-LUW you might try additional options in the connection string to tell the JRE how to access the client side keystore into which you already imported the server certificate. Specifically sslTrustStoreLocation=/path/to/.keystore;sslTrustStorePassword=whatever; . Note that I did not need these options if using Db2-on-cloud (liquibase worked correctly with SSL to Db2-on-cloud once I added DigiCertGlobalRootCA.crt to my keystore (although even that may be unnecessary) , but I did not try Db2-warehouse-on-cloud as I don't use that service.
I'm wanting to connect to an Azure SQL Server from jdbc.
I copy the connection string from the azure management console. It is something like:
jdbc:sqlserver://XXXX.database.windows.net:1433;database=YYYY;user=ZZZZZ#XXXX;password=PPPPPPPPPPP;encrypt=true;hostNameInCertificate=*.database.windows.net
When I try and connect with this value I get the following error:
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not
establish a secure connection to SQL Server by using Secure Sockets
Layer (SSL) encryption. Error:
"java.security.cert.CertificateException: Failed to validate the
server name in a certificate during Secure Sockets Layer (SSL)
initialization. The server name is *.database.windows.net, the name in
certificate is data.am2-1.database.windows.net.
Then if I change the *.database.windows.net to data.am2-1.database.windows.net as it says in the exception it works fine.
So is it a problem to set this name? I feel like if it is a wild card as default then it is probably going to change? and when it does I assume I won't be able to connect anymore.
Has anyone else had this issue? I am using the most up to date jdbc drivers for SQL Server that I could find.
Turns out an upgrade of the sql server jdbc version to version 4.0 cleaned up the issue.
I've got the same issue on JDBC driver version 4.1, downgrading to 4.0 resolved issue
You can also add trustServerCertificate=true in your connection string, but it's not recommended from a security perspective.
I have a web application that uses a local SQL Server Express database (a.k.a. ~/App_Data/ASPNETDB.MDF).
When I deploy to IIS 7.0 on Windows 2008 Standard (SP2), I get the error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified)
The error message goes on to offer some advice
SQLExpress database file auto-creation error:
The connection string specifies a local Sql Server Express instance
using a database location within the application's App_Data directory.
The provider attempted to automatically create the application
services database because the provider determined that the database
does not exist. The following configuration requirements are necessary
to successfully check for existence of the application services
database and automatically create the application services database:
If the application is running on either Windows 7 or Windows Server
2008R2, special configuration steps are necessary to enable
automatic creation of the provider database. Additional information
is available at: http://go.microsoft.com/fwlink/?LinkId=160102. If
the application's App_Data directory does not already exist, the web
server account must have read and write access to the application's
directory. This is necessary because the web server account will
automatically create the App_Data directory if it does not already
exist.
If the application's App_Data directory already exists, the web
server account only requires read and write access to the
application's App_Data directory. This is necessary because the web
server account will attempt to verify that the Sql Server Express
database already exists within the application's App_Data directory.
Revoking read access on the App_Data directory from the web server
account will prevent the provider from correctly determining if the
Sql Server Express database already exists. This will cause an error
when the provider attempts to create a duplicate of an already
existing database. Write access is required because the web server
account's credentials are used when creating the new database.
Sql Server Express must be installed on the machine.
The process identity for the web server account must have a local user profile. See the readme document for details on how to create a
local user profile for both machine and domain accounts.
I don't understand how to troubleshoot 4. (where can I find the "readme document"?). However, the other items look correct to me.
Specifically...
The app pool in question is running as NETWORK SERVICE (not Application Pool Identity)
The user NETWORK SERVICE has Full Control of App_Data (do I understand correctly that it does NOT need Read/Write for App_Data's parent, since App_Data is already created?)
Interestingly, if I copy ASPNETDB.MDF and ASPNETDB.LDF from my development machine to the production App_Data, the error changes:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified) Description: An unhandled exception occurred during the
execution of the current web request. Please review the stack trace
for more information about the error and where it originated in the
code.
Exception Details: System.Data.SqlClient.SqlException: A
network-related or instance-specific error occurred while establishing
a connection to SQL Server. The server was not found or was not
accessible. Verify that the instance name is correct and that SQL
Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified)
What am I missing?
I had the same error before and the problem was that my SQL Server service was stopped, this is pretty weird but sometimes they just crash,I had to reinstall SQL Server cause the service didn't even alloud me to start it,so you may want to check this.
I ended up moving the relevant tables to a new SQL Server database because I could not resolve the permissions issue.
That is the recommended approach anyhow for a production application, though it seems unfortunate that it was so hard (in terms of determining how to configure security) to deploy the ASPNETDB.MDF variant for a very low-volume website.