¿Cuáles son los casos de uso para definir algo que no sea el hash SHA1 predeterminado en un CSR? ¿Es para proteger la firma digital, las claves públicas / privadas? ¿Qué está protegiendo exactamente?
En realidad no es un hash SHA1 en la CSR. Es una firma del mensaje.
Por simplicidad, asumiré que estamos hablando de certificados RSA, donde la clave pública es (N, e) (el módulo y el exponente público que típicamente es 65537) y la clave privada es (N, d) (la módulo y el exponente privado que puede calcularse fácilmente a través del algoritmo extendido de Euclides si puede factorizar el módulo en p y q).
Un certificado es simplemente una clave pública, con algunos metadatos (por ejemplo, quién es usted, a qué dominio se aplica el certificado, quién firmó el certificado), más la firma del certificado.
En RSA, usted firma un mensaje adjuntando una firma al final del mensaje. Obtiene la firma haciendo primero un hash en el mensaje y luego haciendo una exponencia modular en ese hash con su exponente privado. Esa es la firma es S = H(m)^d mod N . Tenga en cuenta que cualquier persona con la clave pública puede verificar la firma calculando S^e mod N y verificando que coincida con el hash del mensaje. Tenga en cuenta que, si no tiene la clave privada, no puede construir una firma válida para el mensaje, por lo que esto evita la manipulación del certificado.
Un CSR es una solicitud de firma de certificado, pero básicamente es solo un certificado autofirmado que crea en una máquina local, por lo que le puede dar a una CA que firme (para que la CA nunca obtenga su clave privada). Así que construyes localmente dos primos grandes, los multiplicas para encontrar el módulo y calculas el exponente privado. Usted agrega sus metadatos sobre usted a su CSR. En buena medida, usted firma inmediatamente su certificado con la clave privada asociada con la clave pública contenida en el certificado.
Esto evita que alguien altere su CSR en tránsito hacia la CA (es decir, cambie los detalles de su organización, contraseña de desafío, número de serie, sin cambiar el módulo / exponente privado).
Probablemente este no sea el ataque más devastador, ya que aún debe confiar en que CA actuará de manera confiable, y no hay razón para regalar sus CSR a terceros. Sin embargo, es sencillo firmarlo, no requiere ningún esfuerzo adicional, por lo que generalmente se realiza.
El RFC para CSRs, enlace , en realidad da una razón diferente por la que se firma el CSR. No dice nada acerca de evitar que se modifique la CSR en tránsito, pero dice que es para evitar que alguien solicite un certificado para una clave que no es de ellos (y dice que esto es solo un problema menor):
"Nota 2 - La firma en la solicitud de certificación impide que entidad de solicitar un certificado con la clave pública de otra parte. Tal ataque le daría a la entidad la habilidad menor de pretender ser el originador de cualquier mensaje firmado por la otra parte. Esta El ataque es significativo solo si la entidad no conoce el mensaje. está firmado y la parte firmada del mensaje no identifica la firmante. La entidad aún no podría descifrar mensajes destinado a la otra parte, por supuesto. "
(en la página 4).
No creo que la idea de 'impide que la CSR se modifique en tránsito' tenga mucho sentido (¿o algo así?). Por lo que puedo ver, cualquier ataque MITM práctico requiere que el atacante esté en posición de interceptar la comunicación en ambas direcciones, por lo que pueden sustituir un CSR completamente diferente por un par de claves que realmente controlan la mitad privada de.
No puedo ver un escenario plausible donde cualquier tipo de 'ataque' plausible pueda ser llevado a cabo por una parte sentada entre un remitente de CSR y una CA que no puede cambiar la clave pública, a menos que esté postulando a un atacante. quien de alguna manera ganaría algo al jugar con los metadatos del certificado y un remitente que no se molesta en verificar los metadatos en el certificado que se obtiene de la solicitud ...
Lea otras preguntas en las etiquetas hash digital-signature certificates openssl