Nel tuo secondo screenshot vedi che il server invia il suo ServerHello e nessun Certificate Request successivo ... ma neanche Certificate . Il server procede immediatamente con una ChangeCipherSpec , come se tutta la crittografia asimmetrica fosse già stata eseguita; e questo è esattamente il caso. Questa è una stretta di mano abbreviata in cui sia il client che il server ricordano i segreti della sessione di una precedente connessione e acconsentono a usarli di nuovo. Quando una sessione è così ripresa , non vi è alcun certificato, né dal client, né dal server. Il client invia in ClientHello una copia dell'ID di sessione della sessione precedente e il server sceglie di riprendere effettivamente quella sessione.
Idealmente va bene; se la sessione precedente utilizzava un'autenticazione con cui il server si trova a proprio agio (ad esempio, un certificato client è stato effettivamente mostrato), il riutilizzo della sessione implica il riutilizzo dello stato di autenticazione. Se il server è non a suo agio con esso, può rifiutare il tentativo di ripresa (cioè ignorare l'ID di sessione inviato dal client e procedere con una normale stretta di mano) o applicare una nuova handshake all'interno il primo. In un mondo pratico e realistico, le cose non sono sempre l'ideale, quindi il codice server può accettare di riutilizzare la sessione, quindi decidere che non dovrebbe averlo fatto e nascondere la vergogna chiudendo bruscamente la connessione.
I parametri della sessione SSL sono memorizzati nella RAM, quindi riavviare il client e / o il processo del server dovrebbe svuotare tali cache e consentire almeno di ottenere un'immagine più chiara di ciò che accade. Potrebbe anche risolvere il problema del tutto (questa è la versione leggera di "prova un riavvio", una cura ben nota per molti disturbi legati a Windows).
