Enforcing Policy Server TLS1.2 handshake to LDAP Policy, User Stores
search cancel

Enforcing Policy Server TLS1.2 handshake to LDAP Policy, User Stores

book

Article ID: 189441

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

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