En su segunda captura de pantalla, verá que el servidor envía su ServerHello y no hay un subsiguiente Certificate Request ... pero tampoco un Certificate . El servidor procede inmediatamente con un ChangeCipherSpec , como si ya se hubiera hecho todo el cifrado asimétrico; y ese es exactamente el caso. Este es un saludo abreviado en el que tanto el cliente como el servidor recuerdan los secretos de la sesión de una conexión anterior, y aceptan usarlos nuevamente. Cuando una sesión se reanuda , no hay certificado, ni del cliente, ni del servidor. El cliente envía a ClientHello una copia del ID de sesión de la sesión anterior, y el servidor elige reanudar esa sesión.
Idealmente, esto está bien; Si la sesión anterior usó una autenticación con la que el servidor se siente cómodo (por ejemplo, se mostró un certificado de cliente), entonces reutilizar la sesión implica reutilizar ese estado de autenticación. Si el servidor no se siente cómodo con él, puede rechazar el intento de reanudación (es decir, ignorar el ID de sesión como lo envió el cliente, y proceder con un saludo completo normal) o imponer un nuevo intercambio dentro de el primero. En un mundo práctico y realista, las cosas no siempre son ideales, por lo que el código del servidor puede aceptar reutilizar la sesión, luego decide que no debería haberlo hecho y oculta su vergüenza al cerrar bruscamente la conexión.
Los parámetros de la sesión SSL se almacenan en la memoria RAM, por lo que reiniciar el cliente y / o el proceso del servidor debe vaciar dichos cachés y al menos permitirle obtener una imagen más clara de lo que sucede. También podría solucionar el problema por completo (esa es la versión ligera de "try a reboot", una solución conocida para muchas dolencias relacionadas con Windows).
