Description of problem:
I'm not entirely sure this should be open against Hammer, because the issue exists independently from the component that tries to authenticate.

LDAP authentication failures are ofter reported as failures in other components of the stack, making it hard to spot and work on.

i.e. :

2016-06-10 16:52:08 [I] Completed 500 Internal Server Error in 116ms (Views: 0.4ms | ActiveRecord: 0.9ms)
2016-06-10 16:52:08 [D] With body: {"displayMessage":"SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A","errors":["SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A"]}

500 internal server error is misleading, if the ssl issue is on ldaps connection. Only with debug things are a little bit better:

2016-06-10 16:52:08 [I] Processing by Katello::Api::V2::PingController#index as application/json;version=2
2016-06-10 16:52:08 [I]   Parameters: {"api_version"=>"v2", "ping"=>{}}
2016-06-10 16:52:08 [D]   User Load (0.6ms)  SELECT "users".* FROM "users" WHERE "users"."lower_login" = 'tugnusatapi' LIMIT 1
2016-06-10 16:52:08 [D]   AuthSource Load (0.4ms)  SELECT "auth_sources".* FROM "auth_sources" WHERE "auth_sources"."id" = 4 LIMIT 1
2016-06-10 16:52:08 [D] LDAP-Auth with User tugnusatapi
2016-06-10 16:52:08 [E] OpenSSL::SSL::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read finished A
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1132:in `connect'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1132:in `wrap_with_ssl'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1169:in `setup_encryption'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:1116:in `initialize'
/opt/rh/ruby193/root/usr/share/gems/gems/net-ldap-0.3.1/lib/net/ldap.rb:634:in `new'
--
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:140:in `accept_and_process_next_request'
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:108:in `main_loop'
/usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler.rb:441:in `block (3 levels) in start_threads'
/opt/rh/ruby193/root/usr/share/gems/gems/logging-1.8.1/lib/logging/diagnostic_context.rb:323:in `call'
/opt/rh/ruby193/root/usr/share/gems/gems/logging-1.8.1/lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context'

So, while the problem was not with the Satellite, but with the Oracle LDAP server it was trying to authenticate against, it took a very long time to figure out due to the poor error reported.

Version-Release number of selected component (if applicable):
Satellite 6.2

How reproducible:
100%

Steps to Reproduce:
1. Perform an action (through Hammer, for example) that would trigger a SSL handshake
2. Have the server drop the connection
3. Inspect the error reported by the tool used (Hammer, for example)

Actual results:
Unuseful error message such as

2016-06-10 16:52:08 [I] Completed 500 Internal Server Error in 116ms (Views: 0.4ms | ActiveRecord: 0.9ms)

Expected results:
More useful error message, that points out the target LDAP server has dropped the connection or had problems completing the request.

Additional info:
During a SSL handshake steps to establish connection to Oracle LDAP server, the server suddenly drops the TCP connection. To see that, let apply filter:

tcp.stream eq 18

to  test_ldap-cycle-error-ldap03_20160713_14.55.21.pcap and notice:

- client (the Sat server here) sent "Client Hello" handshake
- server (the LDAP server) replied with "Server Hello", "Certificate", "Server Key Exchange" and "Server Hello Done"
- client sent "Client Key Exchange", "Change Cipher Spec" and "Encrypted Handshake message"
- server abruptly terminated the connection by sending FIN packet

See Oracle LDAP logs from the same time in #133.

These failures happen _sometimes_ (with approx. 3% probability) only - see other TCP streams in the flow.

Can you please explain me why?

Background:
- client is a ruby script (see #128) using openSSL client
- server is Oracle LDAP server (a pool of servers behind a proxy)
- these unexpected connection drops cause authentication issues to Satellite6 (user auths against the external LDAP server and that connection sometimes fail)