On Wed, May 20, 2020, Matt Caswell wrote: [Thanks for still helping me with this!]
> Can you test the underlying socket to see if it has been closed down in > an orderly way (i.e. recv() should return 0 on the socket if so)? That Yes, that what happens. So I added some debugging to the client and it shows: SSL info: read server hello write change cipher spec write client hello and I/O layer (only last/relevant part): want_write=523, want_read=5 ... write ... and then want_read=5 -< read=OK, num_read=5 want_write=0, want_read=1 want_read=1 -> read=OK, num_read=1 want_write=0, want_read=5 want_read=5 -> read=TIMEOUT, num_read=0 Explanation: want_write = BIO_ctrl_pending(network_bio) want_read = BIO_ctrl_get_read_request(network_bio) I didn't instrument the write part, only the read part. want_read>0 -> invoke read, check result: read=STATUS, num_read=N So the last read does not get the data the library wants, and hence the client fails and closes the connection. In that moment the server fails in SSL_accept and issues the misleading error message. Now the question seems to be: did the server actually not send the data (not sure how to check that, maybe looking at tcpdump?) or has the client a bug not reading the data?
