Many many moons ago I vaguely remember having a similar issue with java keystore / truststore and microsoft certificates stores.
When you start using SSL for your listener, you could potentially face a large number of issues amoung your toolsets. In my opinion, the most disastrous one is that you cannot monitor your database with Enterprise Manager and a TCPS listener. I tried with 10g, 11g, 12c and I seriously doubt it will come in 13c, even a dozen of ERs have been filled. The best workaround I found is to use a separate listener to monitor your database and monitor the ssl-listener itself with IPC.
Today I had to deal with a driver from Datadirect, which finally works perfectly fine with SSL, but the challenge was to know what to put in the keystore and truststore…
In SQLNET, you use the single-sign-on wallet (cwallet.sso) created by OWM/orapki or ldap.
In Java, per default, you use a java keystore, that you generate with keytool (or even use the default cacerts). There is only a lexical difference between a keystore and a truststore, they could both be the same file. As documented in the JSSE Ref
A truststore is a keystore that is used when making decisions about what to trust
But for some other tools, the java keytool won’t do the trick, if the truststore cannot be of the type JKS.
One common type is the PKCS12. This is the your ewallet.p12 you get with the Wallet Manager.
E.g. from java :
To use single-sign-on, use trustStoreType=SSO as I wrote there : jdbc-ssl
Other command formats are X509 base64 or DER file. The openssl command line allows you easy conversion
openssl pkcs12 -in ewallet.p12 -out file.pem
openssl x509 -outform der -in file.pem -out file.der
or in Windows Explorer, just click on your p12 file and then click on the certificate to export in the certificate store.