Un certificado digital, especialmente el formato X.509 más común utilizado para TLS, tiene varias partes. Tres de los más importantes son el nombre del sujeto, la clave pública del sujeto y la firma del emisor. Los dos primeros le dicen para quién es el certificado (como "* .stackexchange.com") y cuál es la clave pública que corresponde a la clave privada de esa entidad. Simular estas partes le permitiría usar un certificado que se le emitió para interceptar solicitudes a otro servidor (cambiando el nombre del sujeto), o usar su propio par de claves pública / privada para descifrar el intercambio de claves y descifrar así toda la conexión TLS ( reemplazando la clave pública del sujeto con su propia clave pública). Por lo tanto, el certificado debe estar protegido contra la manipulación y el destinatario del certificado debe poder saber si el certificado fue falsificado o no (después de todo, usted podría simplemente rellenar los campos del asunto). Ahí es donde entra la firma.
Las firmas digitales se crean utilizando una clave privada, no una pública, por lo que solo el titular de esa clave privada puede crear la firma. Sin embargo, cualquiera que tenga la clave pública puede verificar la firma. Por lo general, se crea una firma de una cadena de bytes corta, denominada resumen de hash criptográfico (el resultado de una función como SHA-256), porque la criptografía de clave pública / privada es lenta (aunque en teoría podría firmar el certificado completo) . Al verificar la cadena de la firma, se vuelve a convertir en el compendio original. Si la firma verificada no coincide con el resumen del certificado (que el cliente puede computar), entonces el certificado no es de confianza (porque ha sido manipulado o tiene una firma falsa).
Debido a que la única entidad con una clave privada de una CA es (en teoría) la propia CA, solo la CA puede crear firmas que verifiquen utilizando la clave pública de la CA. El cliente no necesita preguntar a la CA si firmó el certificado; Si la CA no firmó el certificado, entonces el certificado no tendría la firma de la CA (a menos que alguien más se haya hecho con la clave privada de la CA, que es el tipo de falla que tiende a poner a una CA fuera del negocio) . Un atacante tampoco puede simplemente tomar la firma de algún certificado válido X y colocarlo en un certificado fraudulento Y, porque cuando se verifique esa firma coincidirá con el resumen (resultado de la función hash) del certificado X, pero no con el resumen del certificado. Certificado fraudulento Y (a menos que el atacante haya encontrado una colisión en la función hash, por lo que nadie confía en los certificados firmados con funciones hash antiguas y rotas como MD5).
Los clientes, como su navegador, saben cuál es la clave pública de la CA porque los certificados de CA confiables (que incluyen claves públicas) están incluidos con su cliente, o incluso con su sistema operativo. Por lo tanto, no puedo simplemente firmar algo con mi propia clave privada y pretender que Verisign lo haya firmado; La clave pública de Verisgn ya es conocida por su cliente y no verificará la firma, por lo que no confiaría en el certificado. Esta confianza se utiliza a menudo transitivamente; una CA raíz (como Verisign) podría decir "Confío en esta llamada CA intermedia, así que firmaré su certificado (incluida la parte que dice que su certificado puede firmar otros certificados), y usted debería confiar en ellos como usted Créeme." La CA intermedia puede firmar un certificado para un sitio web o algo así, que se encuentra en la parte inferior de una "cadena de confianza" que conecta el certificado del servidor web con el certificado de la CA raíz por medio de la CA intermedia.