Forum Discussion

Slumlorde_21011's avatar
Slumlorde_21011
Icon for Nimbostratus rankNimbostratus
Jul 06, 2015

TLS Errors with ApacheDS and LTM

New to SSL/TLS and LTM and trying to get a secure connection between our client and a pool of LDAPS servers. I've exported the certificates we already purchased and imported them into a keystore for our ApacheDS servers to use. I can connect with Apache Directory Studio to each individual node without any errors but when trying to connect to the pool it just times out. Any help you could provide would be appreciated let me know what other info you need!

 

7 Replies

  • So just to be clear, you've installed certificates on the ApacheDS servers and configured them to talk LDAPS (port 636?), correct?

     

    How do you have the virtual server and pool configured? Are you trying to do client side LDAP 389 to server side LDAPS 636?, LDAPS->LDAPS bridging or tunneling (passthrough)?

     

  • I'm using port 636 correct. I'm trying to do Client side LDAPS 636 to Server side LDAPS 636. I'm honestly not sure if its bridging or tunneling, how would I tell? Only ever made pools and changed irules honestly.

     

  • If you're terminating and re-encrypting the SSL, it's bridging. If you're simply passing the SSL straight through (no SSL profiles), then its tunneling. Try to tunnel the LDAPS first and see if that works. If it does, then you're probably looking at an issue in the client and/or server SSL configurations.

     

  • So I've setup tunneling (Assuming just remove both Client and Server SSL Profiles) and I get. Assuming this means I am having other SSL related issues and not F5 issues.

    CONNECTED(00000174)
    
     write:errno=10054
    
     no peer certificate available
    
     No client certificate CA names sent
    
     SSL handshake has read 0 bytes and written 317 bytes
    
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    
     No ALPN negotiated
    
  • You should have a very simple "standard" VIP listening on port 636, with nothing more than a TCP profile applied, and a pool that points to a server (or servers) on port 636. Apply SNAT Automap to enforce return routing if the server can talk directly to the client. At this point you're doing nothing more than layer 4 (TCP) load balancing through the proxy. Does that work?

     

    Where is this error message coming from? Do you get any sort of message when going directly to the server?

     

  • Well it appears that all of this was for naught. The HTTP profile appears to be the culprit. After removing it I was able to create a successful bridge connection! Thanks for your help!

     

  • Right. Didn't think to ask if you had an HTTP profile on an LDAP VIP. ;)

     

    In any case, that would have certainly caused the problem.