gergon dorothy daemiyn
Sherry Galeazzi
I've put the osdt_cert.jar, osdt_core.jar, ojdbc8.jar and oraclepki.jar in the splunk_app_db_connect/drivers directory, and I've tried several entries to put the above files in the java classpath via the General --> JVM Options in the GUI but nothing has seemed to work.
That should get you past the error above, but you might encounter other issues with configuring Oracle Wallets. If you run into other issues, let me know and I'll see what I can post. It might be easier for me to post the whole thing, let me know
Autonomous Database mandates a secure connection that uses Transport Layer Security (TLSv1.2). Depending on the network configuration options, Autonomous Database supports mTLS and TLS authentication.
If your Autonomous Database is on a public endpoint without any ACL, you can add 0.0.0.0/0 as your CIDR ACL and enable TLS authentication. Adding 0.0.0.0/0 as your CIDR ACL is identical to having your Autonomous Database on public endpoint with no ACL.
Applications that use JDBC Thin driver support TLS and mutual TLS (mTLS) authentication. Using mTLS authentication requires that you supply Oracle database credentials including the Oracle wallets or Java KeyStore (JKS) files when connecting to the database.
For applications that use the Universal Connection Pool (UCP) feature of JDBC, it is highly recommended to use 19.13 or higher or 21.3 or higher versions of the JDBC driver. These versions include proper draining behavior to minimize impact to applications when planned maintenance is performed in Autonomous Database. UCP will replenish connections in the pool proactively so that active connections are not impacted by maintenance.
The connection string is found in the file tnsnames.ora which is part of the client credentials download. The tnsnames.ora file contains the predefined service names. Each service has its own TNS alias and connection string.
Verify the connection: You can either use a Java program, a servlet, or IDEs to verify the connection to the database. A simple test is to download DataSourceSample.java or UCPSample.java from JDBC code samples and update the connection URL to have the required TNS alias and pass TNS_ADMIN, providing the path for tnsnames.ora and the wallet files. Also, in the sample source code update the database username and password. For example:
Ready the database details: You can either use a Java program, a servlet, or IDEs to check the connection to your database. A simple test is to download DataSourceSample.java or UCPSample.java from JDBC code samples. In this sample, use the connection URL as shown. Note that the connection DB_URL contains the TNS alias, for example, dbname_high present in tnsnames.ora. You can provide the path for tnsnames.ora file through TNS_ADMIN property as shown in the URL. Make sure to use the database username and password related to your database.
Set JKS related connection properties: Add the JKS related connection properties to ojdbc.properties file. The keyStore and truststore password are the password specified when you downloading the client credentials .zip file.
If you are not able to use the latest 18.3 JDBC drivers, then you can connect to Autonomous Database using 12.2.0.2 or other older JDBC drivers. The 12.2 or older JDBC drivers do not support the ojdbc.properties file. With older JDBC driver versions, you need to pass wallets or JKS related properties either as system properties or as connection properties to establish a connection.
Verify the connection: You can either use a Java program, a servlet, or IDEs to verify the connection to the database. A simple test is to download DataSourceSample.java or UCPSample.java from JDBC code samples and update the connection URL to have the required TNS alias. Also, update the sample source code to use the database username and password. For example:
Set the wallet location: Add the OraclePKIProvider at the end of the provider list in the file java.security (this file is part of your JRE install located at $JRE_HOME/jre/lib/security/java.security) which typically looks like:
Compile and Run: Compile and run the sample to get a successful connection. Make sure to have oraclepki.jar , osdt_core.jar, and osdt_cert.jar, in the classpath. Also, you need to pass the connection properties. Update the properties with the location where tnsnames.ora and wallet files are located.
Verify the connection: You can either use a Java program, a servlet, or IDEs to verify the connection to the database. A simple test is to download DataSourceSample.java or UCPSample.java from JDBC code samples and update the connection URL to have the required TNS alias and pass TNS_ADMIN, providing the path for tnsnames.ora and update the connection URL to have the required TNS alias. Also, in the sample source code update the database username and password. For example:
Compile and Run: Compile and run the sample to get a successful connection. You need to pass the connection properties as shown. Update the properties with the location where tnsnames.ora and JKS files are placed. If you want to pass these connection properties programmatically then refer to DataSourceForJKS.java. For example:
If the client is behind a firewall and your network configuration requires an HTTP proxy to connect to the internet, you need to use the JDBC Thin Client 18.1 or higher which enables connections through HTTP proxies.
To connect to Autonomous Database through an HTTPS proxy, open and update your tnsnames.ora file. Add the HTTP proxy hostname(https_proxy) and port (https_proxy_port) to the connection string. Replace the values with your HTTPS proxy information. For example:
Add the HTTP proxy hostname and port to the connection definitions in tnsnames.ora. You need to add the https_proxy and https_proxy_port parameters in the address section of connection definitions. For example, the following sets the HTTP proxy to proxyhostname and the HTTP proxy port to 80; replace these values with your HTTP proxy information:
Successful connection depends on specific proxy configurations and the performance of data transfers would depend on proxy capacity. Oracle does not recommend using this feature in Production environments where performance is critical.
Configuring tnsnames.ora for the HTTP proxy may not be enough depending on your organization's network configuration and security policies. For example, some networks require a username and password for the HTTP proxy.
which compiles well if you have the $ORACLE_HOME/jlib/oraclepki.jar file in your library path. However, that code threw all kinds of exceptions on me when i ran it. Turns out that, when executing this code, you need osdt_core.jar and osdt_cert.jar as well. (The exceptions will include the names of some classes that are missing, but some of those classes are in osdt_core_fips.jar as well. Took me two hours until i replaced osdt_core_fips.jar with osdt_core.jar, since you get decryption errors, not ClassNotFound exceptions, when you use the wrong one).
To give oracle some credit, section 2.2.1 of the oracle white paper mentions that. Seems Oracle 10 used ojpse.jar instead of the osdt_* jars, but Oracle 11 and 12 both use the osdt_* jars.
A note of caution here: while copied .sso files might not be directly usable in all cases, they still contain all credentials needed to login. I have a hunch that oracle just takes your machine name, user name, and maybe one or two other factors, creates a secret key from them, and encrypts your original file with that key. I doubt that a determined individual would need much longer that a week to write a wallet file decryptor. So you should protect your wallet files just as if they were text files containing a plaintext password.
Turns out that KeyStore.isCertificateEntry lies to you when you deal with user certificates. If the alias myusername has a key, a certificate request, and a certificate, in the wallet, then KeyStore.isKeyEntry("myusername") will return true, as it should. But KeyStore.isCertificateEntry("myusername") will return false, even with the certificate present.
Fortunately, keyStore.getCertificate("myusername") will still return the certificate. Unfortunately, this cost me an afternoon and most part of the evening to figure out, until i decided to load up the oraclepki.jar in jd-gui.
At the moment I don't have a database to connect to. I'm trying to get one at my company. Nevertheless, I used the information on the website and did a test job with an Oracle connection. In the component the settings are: connection type "Oracle service name" and DB version "Oracle 18 and above". Also, I have host, port, database, scheme, service name (displayed as database) and of course username and password. In the Additional JDBC Parameter field, I would enter the SSL parameters. For a test, I entered "javax.net.ssl.trustStore="truststore.jks"". The code generator throws the error: javax.net.ssl.trustStore cannot be resolved to a type. How can I fix this and is this the correct place to enter the SSL information?
thank you for your answer. I changed the database connection and tested it. I get a list of missing modules: oraclepki.jar, osdt_cert.jar and osdt_core.jar - all in version 12.2.0.1. Do I have to use this version for the jar files or can I download the newest version from Maven repository?
Hello romarra,
did you also register the additional library files that are necessary for Oracle wallet:
oraclepki.jar , osdt_core.jar , and osdt_cert.jar?
To do so either copy all the jars into a directory and register the directory or add all files separately as described in the db documentation. More details about the configuration can be also found in the Oracle documentation.
Hello romarra,
sorry for the long silence. Can you please try to use a Credential Input node with no user name and password as in the attached workflow. Even if you select none as authentication method the DB framework will add an empty password property to the connection string which seems to cause problems with Oracle wallet. This is a bug and I have opened a ticket to fix this.
Bye
Tobias