Enforcing Policy Server TLS1.2 handshake to LDAP Policy, User Stores
Article ID: 189441
Updated On:
Products
Issue/Introduction
When running a Policy Server, how could the usage of TLSv1.2 be
enforced when connection to backend LDAP Policy or User Stores ?
How to enable SSL debug logs too when connecting to these LDAP
Directory ?
Environment
Policy Server 12.8SP3 on RedHat 6;
Policy Store on LDAP ODSEE 11gR2;
Resolution
At first glance, in SSL handshake, the version of SSL is chosen by the
server. In the case of Policy Server connecting to the LDAP User
Store, the LDAP User Store is the server and Policy Server is
the client.
So the Policy Server will tell the LDAP User Store which versions
of TLS it can handle, in case of 12.8SP3, TLSv1.0, TLSv1.1 and
TLSv1.2.
Then the LDAP User Directory will select the version and send the
certificate (1).
Usually, the Server will use the highest version that the Client
supports. To ensure that no connection will be done outside TLSv1.2,
configure the Server (LDAP Server) to only support TLSv1.2. This might
hurt compatibility with other software that doesn't support it.
To see which protocol is supported by the LDAP ODSEE version, run the
openssl command as described in this Oracle document (2).
Running network traces on the Policy Server will help. The TLS packets
exchanged between the Policy Server and the LDAP User Directory will
show the version of TLS.
Additional Information
(1)
What Happens in a TLS Handshake? | SSL Handshake
The exact steps within a TLS handshake will vary depending upon the
kind of key exchange algorithm used and the cipher suites supported
by both sides. The RSA key exchange algorithm is used most often. It
goes as follows:
The 'client hello' message: The client initiates the handshake by
sending a "hello" message to the server. The message will include
which TLS version the client supports, the cipher suites
supported, and a string of random bytes known as the "client
random."
The 'server hello' message: In reply to the client hello message,
the server sends a message containing the server's SSL
certificate, the server's chosen cipher suite, and the "server
random," another random string of bytes that's generated by the
server.
https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
(2)
ODSEE - What Versions of SSL and TLS are Supported by the Latest Version of the Directory Server (Doc ID 2047989.1)
$ openssl s_client -tls1_2 -connect <HOST2>:<SSL_PORT2>
CONNECTED(00000003)
depth=0 O = Sun Microsystems, CN = Directory Server, CN = <SSL_PORT2>, CN = <HOST>
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Sun Microsystems, CN = Directory Server, CN = <SSL_PORT2>, CN = <HOST>
verify return:1
---
Certificate chain
0 s:/O=Sun Microsystems/CN=Directory Server/CN=<SSL_PORT2>/CN=<HOST>
i:/O=Sun Microsystems/CN=Directory Server/CN=<SSL_PORT2>/CN=<HOST>
---
Server certificate
-----BEGIN CERTIFICATE-----
<CERTIFICATE INFORMATION>
-----END CERTIFICATE-----
subject=/O=Sun Microsystems/CN=Directory Server/CN=<SSL_PORT2>/CN=<HOST>
issuer=/O=Sun Microsystems/CN=Directory Server/CN=<SSL_PORT2>/CN=<HOST>
---
Acceptable client certificate CA names
/O=Sun Microsystems/CN=Directory Server/CN=<PORT>/CN=<HOST>
/O=Sun Microsystems/CN=Directory Server/CN=<SSL_PORT2>/CN=<HOST>
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 1140 bytes and written 387 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: <SESSION_ID>
Session-ID-ctx:
Master-Key: <KEY>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1439228320
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
closed
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=294963085003094&parent=EXTERNAL_SEARCH&sourceId=HOWTO&id=2047989.1&_afrWindowMode=0&_adf.ctrl-state=1bvpyur44x_53
Feedback
