Peer logs filled with TLS handshake error #fabric #fabric-questions #ssl #tls


chintanr97@...
 

Hi Team, in peer logs we keep seeing following error messages:
```
2021-01-12 14:36:08.217 UTC [core.comm] ServerHandshake -> ERRO 2278 TLS handshake failed with error read tcp <ip1>:7052-><ip3>:60870: i/o timeout server=ChaincodeServer remoteaddress=<ip3>:60870
2021-01-12 14:36:08.218 UTC [core.comm] ServerHandshake -> ERRO 2279 TLS handshake failed with error read tcp <ip1>:7051-><ip3>:60872: i/o timeout server=PeerServer remoteaddress=<ip3>:60872
2021-01-12 14:36:08.573 UTC [core.comm] ServerHandshake -> ERRO 227a TLS handshake failed with error read tcp <ip1>:7052-><ip4>:54263: i/o timeout server=ChaincodeServer remoteaddress=<ip4>:54263
2021-01-12 14:36:08.575 UTC [core.comm] ServerHandshake -> ERRO 227b TLS handshake failed with error read tcp <ip1>:7051-><ip4>:54262: i/o timeout server=PeerServer remoteaddress=<ip4>:54262
2021-01-12 14:36:12.287 UTC [core.comm] ServerHandshake -> ERRO 227c TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip2>:65264
2021-01-12 14:36:12.601 UTC [core.comm] ServerHandshake -> ERRO 227d TLS handshake failed with error read tcp <ip1>:7052-><ip2>:65265: i/o timeout server=ChaincodeServer remoteaddress=<ip2>:65265
2021-01-12 14:36:13.231 UTC [core.comm] ServerHandshake -> ERRO 227e TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip3>:60887
2021-01-12 14:36:13.233 UTC [core.comm] ServerHandshake -> ERRO 227f TLS handshake failed with error EOF server=ChaincodeServer remoteaddress=<ip3>:60888
```

On our end, we verified the TLS certificates and they seem to be correctly configured with required SANs. I wanted to understand the implication of the "i/o timeout" error and "error EOF" messages.


Matthew Sykes
 

EOF - End of File. It's likely indicating the other end of the connection has closed during the handshake, that a network error occurred, or that a record header with an incorrect length was received.
i/o timeout - the error string included in expired deadline errors. These are generally read timeouts.

The addresses in the errors are telling you the addresses of clients that are closing their connections or failing to send data within a reasonable time. For gRPC, the connection timeout is used as the deadline and covers the TLS handshake and HTTP/2 protocol negotiation. This can be changed for the peer by setting the `peer.connectionTimeout` config key. The default appears to be 5s.

You need to investigate the root cause in your own environment and make appropriate changes.