Last updated on MARCH 08, 2017
Applies to:Oracle Virtual Directory - Version 10.1.4.2 to 10.1.4.3 [Release 10gR3]
Information in this document applies to any platform.
Oracle Virtual Directory (OVD) 10g 10.1.4.2.
Connections to OVD via non-SSL OVD listener ports work fine.
SSL connections were working before with OVDs with server authentication SSL mode, but certificates expired so imported new ones from a different Certificate Authority (CA).
Since then, SSL connections from clients and applications fail.
Knows the expected working behavior with one client app called Apache Directory Studio, so using that to verify the SSL connection to OVD. Apache Studio is supposed to immediately trust the certificates and when viewing the certificate, it should show the chain including the root or trust certificate, the intermediate certificate, and the individual certificate.
But instead the app prompts with choices to trust or not trust, whereas it should implicitly trust and not prompt for anything at all.
In fact, when pointing the app to another vendor's LDAP server also configured for SSL, the client behaves as desired and does not prompt to trust any certificates.
With OVD, can trust for the session for example, but the other client applications are not able to do this, nor they are expected to.
From the OVD Server keystore, able to see all the certificates of the chain individulally with keytool list from command line. Also able to see them the same way in OVD Manager > Manage Certificates.
In the OVD server access.log and vde.log, can see some bind attempts from cn=admin, but no errors or SSL related errors or messages at all from the clients connection attempts.
It seems each certificate are imported to OVD keystore ok but they are not interpreted together, in a chain when the client accesses it.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms