The first place to check is the server’s access log.
If the client can successfully establish a TCP connection to the server, which
must happen before TLS negotiation can begin, the access log should show a
CONNECT message with the source and destination address and port
for the connection, the protocol, and the selected client connection policy. If you
don’t see that
CONNECT message, then that suggests that the client
might not be able to communicate at all with the server. That might mean there is a
network problem, that a firewall is blocking the communication, or something as simple
as the client is trying to use the wrong address or port.
If you see the
CONNECT message in the access log, then that
message should include a
conn element that provides the connection ID
for that connection. You can then use the
search-logs tool to see if
there are any other log messages for that client connection. For example, if the
connection ID is 12345, then the following command can show the complete set of log
messages for that connection.
$ bin/search-logs --logFile logs/access conn=12345
When trying to use LDAPS, the next log message that you see should either be a
SECURITY-NEGOTIATION or a
SECURITY-NEGOTIATION messages should indicate that the client and
server successfully completed the negotiation process and should include details about
that negotiation, like the TLS protocol and selected cipher suite. If you see a
SECURITY-NEGOTIATION message, then it indicates that the problem
likely happened after the TLS session was established.
On the other hand, if the
CONNECT message is immediately
followed by a
DISCONNECT message, then that suggests that the problem
is likely a failure in the TLS negotiation process. In such cases, the message should
reason element that provides more information about the
reason for the disconnect. If the failure occurred during TLS negotiation, then how
useful that message is depends at least in part on whether the failure occurred on the
client or the server. If the server decided to abort the negotiation, then the message
ideally contains the exact reason. If the problem occurred on the client, then the log
message likely only contains the general category for the failure. That is because the
TLS protocol does not provide a mechanism for conveying detailed error messages but only
offers a basic alert mechanism with a fixed set of alert types. For example, if the
problem is that the client did not trust the certificate chain that the server presented
to it, the client might know exactly why it rejected the chain, but the server probably
only gets an alert like
certificate_unknown. In such cases, you might
need to see if the client provides any more detail about the problem.
If the access log does not appear to provide any useful information, then you might also want to check the server error log. The error log won’t normally include information about problems related to client communication, but it can offer useful information in certain circumstances, such as if an internal error within the server is interfering with the communication attempt.