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 DISCONNECT message. 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 include a 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.