Un certificado de clave pública es la combinación firmada entre una clave pública, identificadores y posiblemente otros atributos. Quienes firman este documento afirman efectivamente la autenticidad de la vinculación entre la clave pública y el identificador y estos atributos, de la misma manera que una autoridad emisora de pasaportes afirma la vinculación entre la imagen y el nombre en un pasaporte, como varias otras piezas de Información (nacionalidad, fecha de nacimiento, ...).
Primero, un par de aclaraciones sobre la terminología:
-
Estrictamente hablando, no existe tal cosa como un "certificado SSL". La mayoría de las veces, esta es una expresión corta para el "Certificado X.509 utilizado para SSL / TLS". (SSL / TLS también es capaz de usar otros tipos de certificados, como certificados OpenPGP , aunque esto es menos común). / p>
-
Su uso de "cifrado" y "descifrado" es incorrecto aquí. En criptografía de clave pública:
- La clave privada se usa para firmar y descifrar / descifrar .
- La clave pública se utiliza para verificar firmas y cifrar / encriptar .
Consulte el glosario de especificación TLS :
criptografía de clave pública: una clase de técnicas criptográficas que emplean cifrados de dos claves. Los mensajes cifrados con la clave pública pueden
Solo se descifra con la clave privada asociada. A la inversa,
Los mensajes firmados con la clave privada se pueden verificar con el público.
llave.
Puede parecer que no importa esta distinción en terminología, porque estas operaciones son aproximadamente las mismas en lo que respecta a RSA (de hecho, encontrará rutinas subyacentes llamadas RSA_private_encrypt en OpenSSL), pero (a) esto no No trabaje para DSA y (b) no entender esta diferencia fundamental puede llevarlo a cometer errores en lo que respecta a su esquema de seguridad general.
En particular, el propósito del cifrado es ocultar algo. Cuando se habla de "cifrar con una clave privada" aquí, no tiene ningún sentido ya que nadie conoce la clave pública. Además, no se requiere que la clave pública del emisor mire dentro de un certificado que este emisor haya firmado, porque todo (vea TBSCertificate structure ) está claro para que cualquiera pueda verlo de todos modos. Aquí no hay nada oculto.
(Lo que se hace para firmar con RSA es, de hecho, más o menos la misma operación que el cifrado, pero con la clave privada, aplicada a un resumen criptográfico del mensaje a firmar, que normalmente se realiza con SHA-1 para certificados en la actualidad).
Lo que su certificado de servidor pretende probar es que la CA ha verificado de alguna manera el enlace entre su nombre de host y su solicitud de certificado (más específicamente, la clave pública en su solicitud de certificado). Como mínimo, tendría un correo electrónico con el propietario del nombre de dominio (para los certificados de dominio validados). (Consulte las distinciones entre los modos de validación aquí .)
El contenido del certificado emitido debe cumplir con RFC 3280 / RFC 5280, que define cómo los clientes deben verificar y validar el certificado. Esto definirá qué atributos se pueden usar, en particular los atributos de uso clave (extendido) por lo general, por ejemplo. "Servidor TLS".
Como resultado, su certificado de servidor X.509 se unirá:
- Una clave pública (para la cual tiene la clave privada).
- Un nombre de emisor (el DN del sujeto del certificado de CA).
- Un nombre de servidor (de acuerdo con RFC 2818 Sección 3.1 o RFC 6125), en la extensión del Nombre Alternativo del Asunto o en el Nombre Común del Nombre Distinguido del Asunto.
- Extensiones de uso.
- Posiblemente otras extensiones (críticas o no), por ejemplo. Políticas de certificados EV.
Todo esto se encuentra en la TBSCertificate structure del certificado X.509. Luego esto
la estructura se digiere con un algoritmo de hash criptográfico (por ejemplo, SHA-1) y se firma con la clave privada de la AC para formar la firma ( signatureValue en el Certificate resultante).
Cuando se usa el certificado, el cliente puede verificar esta firma (usando la clave pública de la CA que conoce, o construyendo una ruta de certificación usando múltiples certificados de CA para uno de los anclajes de confianza que conoce), verifique que los atributos de uso son compatible con el uso de SSL / TLS y verifique que el nombre de host que solicitó coincida con el nombre para el que se emitió.