¿Es correcta esta explicación sobre cómo funcionan las firmas de certificados SSL?

El hash para la firma de un certificado dado es fijo, pero un servidor puede tener más de un certificado, y también lo es un cliente. TLS1.2 agrega una extensión de saludo que permite al cliente especificar qué algoritmos de firma puede manejar, como pares de hash + PKC como SHA256 + RSA o SHA384 + ECDSA; el servidor debe elegir y enviar un certificado adecuado si tiene uno. Si no tiene un certificado que el cliente pueda manejar, demasiado malo, a menos que tanto el cliente como el servidor acepten un conjunto de cifrado "anónimo" que no requiera ningún certificado, que sea inseguro contra ataques activos y, por lo tanto, generalmente esté prohibido.

De manera similar, si el servidor solicita un certificado de cliente, también conocido como autenticación de cliente, lo cual es raro, en 1.2 especifica algoritmos de firma aceptables y el cliente debe elegir en consecuencia. Para todas las versiones, el cliente (también) debe considerar la lista de CA aceptables especificadas por el servidor, a menos que el servidor haya elegido dejar esa lista vacía, lo que es aún más raro.

Además, el servidor no envía directamente información sobre lo que "apoya". ServerHello elige exactamente un conjunto de cifrado y un algoritmo de compresión de las listas ofrecidas por ClientHello. Si usa ECC, el Cert subsiguiente y posiblemente ServerKeyExchnage seleccionan una curva y un formato de puntos entre los que se ofrecen. No hay información sobre otras suites, compresiones o curvas y puntos que el servidor admita y pueda usar en respuesta a un ClientHello diferente. El servidor también elige una versión de protocolo en el rango ofrecido por el cliente; si el servidor elige por debajo del máximo del cliente, es una apuesta segura que el servidor no admite más, pero si acepta el máximo del cliente, podría ser mejor. Contraste con SSH donde ambos lados envían listas completas y calculan la intersección; pero SSH normalmente no usa certificados en absoluto, solo publicidades desnudas.

De hecho, no hay negociación, pero la cita sigue siendo correcta en su mayoría.

El certificado es simplemente estático. Si tiene el archivo de certificado y openssl instalado, puede ver exactamente lo que contiene con esta línea de comando:

openssl x509 -in <crtfile> -noout -text

La misma información también está disponible en los navegadores web, pero debes ser un poco cuidadoso; usar openssl es mejor Lo que el navegador web le muestra no es tan simple como lo que openssl le muestra, y el navegador web agregará cierta información adicional que se deriva del certificado. En particular, puede ver tanto una huella digital SHA1 como una huella digital SHA256: no se confunda, no están en el propio certificado.

Cuando mira la firma dentro del certificado, generalmente solo verá una firma, y obviamente será la que se está utilizando, si el cliente no admite ese algoritmo de firma, no hay nada en lo que puedan estar de acuerdo. en, y eso es el final de la misma. Si el cliente lo admite, puede comenzar a usar ese certificado de inmediato.

También es concebible que un certificado contenga varias firmas que utilicen diferentes algoritmos (aunque no creo que el formato del certificado realmente lo admita; esta idea sería solo teórica), pero incluso así, lo mismo seguiría siendo válido.

Entonces, la "negociación" consiste básicamente en que el servidor envía el certificado con el algoritmo de firma y le dice al cliente "aquí está, lo tomas o lo dejas".