Solución:
TL; resumen de DR:
La validez de un certificado de servidor se establece mediante:
- Verificación del nombre de host
- Verificación de las firmas de toda la cadena de certificados
- Realización de comprobaciones adicionales de metadatos para cada certificado.
- Comprobación del estado de revocación de cada uno de los certificados implicados
- Verificar si el certificado raíz autofirmado de la cadena se encuentra entre los certificados en los que se confía por defecto
Explicación
Supongamos que desea conectarse a https://mail.google.com (¡puede probar esto en su navegador!).
El servidor (real) responderá con un certificado que se emite a mail.google.com, es decir, en el campo ‘Asunto’ del certificado encontrará el Nombre común (CN) ‘mail.google.com’ – cf. RFC 5280 para obtener detalles sobre los campos de los certificados. El hecho de que el asunto esté vinculado a la URL del sitio es muy importante para la seguridad de todo el modelo, y su implementación de TLS lo verifica activamente (“verificación del nombre de host”), porque de lo contrario habría espacio para Man-In- Los ataques del medio. Es decir, alguien podría adquirir un certificado válido y hacerse pasar por mail.google.com sin que usted se dé cuenta.
Además de la verificación del nombre de host, su implementación de TLS también verificará la “validez” del certificado. Todo el procedimiento es bastante complejo e incluye verificar la confiabilidad del certificado, pero además se verificarán muchas otras cosas, más sobre eso en un minuto.
Si ve el certificado de Google Mail en su navegador, notará que en realidad hay Tres certificados mostrados:
- mail.google.com
- Thawte SGC CA
- Autoridad de certificación primaria pública de clase 3 (VeriSign)
El modelo es que hay algunas (bueno, desafortunadamente ya no tan pocas) autoridades de certificación raíz confiables (“CA raíz”) que puede elegir por su cuenta o (más probablemente) que vienen preconfiguradas con su software (por ejemplo, navegador) en los que se confía ciegamente. Estas autoridades de confianza forman los anclajes de todo el modelo de confianza de “PKI” (Infraestructura de clave pública). La idea básica es que las entidades de confianza pueden emitir certificados a otras autoridades y otorgarles permiso para volver a emitir certificados (estas autoridades se denominan autoridades de certificación intermedias). Las CA intermedias pueden volver a aplicar de forma recursiva este procedimiento hasta cierto punto, el número de CA intermedias entre un certificado de entidad final real y un certificado de CA raíz es generalmente limitado.
En un momento, una CA intermedia emitirá certificados a una “entidad final” (“mail.google.com” en nuestro ejemplo). Ahora, el proceso de emisión de un certificado significa en realidad que la parte que solicita un certificado creará primero un par de claves pública / privada y las usará para autenticar una solicitud de certificado que se envía a la autoridad de certificación. La autoridad emisora crea un certificado para la entidad subordinada (ya sea CA intermedia o entidad final) “firmando” ese certificado usando su propia clave privada usando un algoritmo asimétrico como RSA e incluyendo adicionalmente la clave pública de la parte solicitante dentro de la nueva certificado generado. La CA raíz posee un certificado autofirmado, es decir, la CA raíz es la única autoridad que puede firmar su propio certificado e incluir su propia clave pública. La clave privada permanece oculta en todo momento, por supuesto.
La naturaleza recursiva del proceso de emisión de certificados implica que para cada certificado de entidad final existe una forma única de establecer una “cadena” de certificados que conduce a una autoridad de certificación raíz. Ahora, cuando se le presente un certificado de entidad final mientras intenta conectarse a un sitio protegido por TLS, el siguiente procedimiento se aplicará de forma recursiva hasta que obtenga un certificado de CA raíz:
- Busque el certificado de la autoridad que emitió el certificado que se va a validar (consulte RFC 5280 para obtener más detalles). Si no se encuentra ninguno: salga con error.
- Tome la clave pública del certificado emisor y verifique la firma del certificado a ser validado usando esta clave pública.
- Verifique muchas cosas adicionales, como si el certificado no ha caducado ni es válido todavía, “restricciones de política”, “usos de claves”, “usos de claves extendidos” … (nuevamente, los detalles sangrientos están en el RFC) .
- Estado de revocación del certificado (más sobre eso más adelante)
Si todas las comprobaciones fueron positivas, finalmente terminará con un certificado autofirmado, es decir, donde el sujeto también es el emisor (como el certificado VeriSign en nuestro ejemplo). Ahora lo último que tienes que verificar es si este certificado se encuentra entre aquellos en los que confías ciegamente: si es así, todo está bien y la conexión será exitosa, si no, el intento de conexión será rechazado.
Como si esto no fuera lo suficientemente complicado ya, las comprobaciones descritas hasta ahora no manejan casos en los que los certificados que una vez fueron válidos se vuelven deshonestos repentinamente, por ejemplo, los casos en los que se roba un certificado o las claves privadas se ven comprometidas (piense en Comodo y DigiNotar). En estos casos, el procedimiento normal es “revocar” los certificados que no funcionan, es decir, desea marcarlos como inválidos a partir de un punto distinto en el tiempo (expirarán en algún momento de todos modos, pero por el resto de ese período ya estarán marcados como inválidos). Para estos casos, las CA tienen la posibilidad de emitir CRL (un catálogo de certificados declarados no válidos) o respuestas OCSP (información para uno o, en casos excepcionales, un conjunto de certificados) que brindan a los clientes información sobre si un certificado determinado se ha marcado como no válido. o no. Se debe verificar el estado de revocación para todos los certificados en una cadena, si uno de ellos se marca como no válido, entonces el certificado de la entidad final no es confiable y la conexión también debe rechazarse.
Los certificados SSL están firmados por una autoridad de certificación (CA), que es alguien en quien el usuario ya confía (o más probablemente, las personas que diseñaron su sistema operativo confían).
La CA firma digitalmente el certificado mediante cifrado de clave pública. La explicación básica es que la CA tiene una “clave privada” y una “clave pública” que todos conocen. A través de algunas matemáticas que no entiendo, la CA puede crear una firma usando su clave privada que se puede verificar fácilmente con su clave pública (pero la clave pública no se puede usar para crear una nueva firma).
Cuando obtiene un certificado SSL de un servidor, obtiene la clave pública del servidor y una firma de una CA que dice que es válida (junto con alguna otra información). Si conoce y confía en esa CA, puede verificar la firma y determinar si es válida. También puede usar una lista de revocación de certificados para asegurarse de que no se revocó.
Básicamente, puede reconocer un certificado SSL incorrecto porque no está firmado por una autoridad de certificación en la que confía.
Cualquier certificado falso que cree será un autofirmado certificado.
El navegador mostrará grandes advertencias de miedo cuando se conecte a un sitio con un certificado autofirmado que el usuario ignorará de inmediato.
Para evitar advertencias, necesita un certificado firmado por una autoridad de certificación en la que confíe el navegador, como VeriSign.
Estas empresas Ojalá asegúrese de ser el propietario del dominio del certificado que están firmando.
Re: Editar: Solo puede crear un certificado no autofirmado si lo firma una CA de confianza.
Se negarán a firmar un certificado para un tema diferente.