Es necesario aclarar el proceso de firma de CSR

Question

Es necesario aclarar el proceso de firma de CSR

#1 de StackzOfZtuff (3 votos)

3

No parece haber mucha información en profundidad sobre el proceso de firma de certificados que no sea:

Guía de uso del protocolo de interoperabilidad de gestión de claves versión 1.2 (PDF)
RFC 2986 - PKCS # 10: Especificación de sintaxis de solicitud de certificación, Versión 1.7

Aquí hay un ejemplo de CSR que creé:

Pegué lo anterior en certlogik.com y eché un vistazo a la salida.

Si lo comprendo correctamente, 4 componentes formarán CertificationRequestInfo :

Versión
Asunto
Información de clave pública
Atributos

Supongo que al usar SHA1 o SHA2, el CertificationRequestInfo se revisa y la salida de hash se cifra mediante la clave privada de la computadora que está creando el CSR.

Cuando llega a la CA, la CA toma el CertificationRequestInfo y ejecuta un hash en él. Luego, también toma el valor cifrado e intenta descifrarlo utilizando la clave pública en el CSR. Si la salida de hash y la salida de hash descifrada coinciden, la CA firmará el CSR.

Por favor corríjame si me equivoco con lo anterior. En este punto, estoy confundido con respecto a qué datos firma realmente la CA (qué datos la CA hace un hash y luego los encripta).

public-key-infrastructure certificates certificate-authority

pregunta Daniel 24.02.2015 - 23:38

fuente

1 respuesta

Lea otras preguntas en las etiquetas public-key-infrastructure certificates certificate-authority

Solución para Enterprise SW Eng. con Github y NPM [cerrado] Seguridad en la lectura de artículos a través de un lector RSS

score 3 · Accepted Answer

Se comprueba la validez de la CSR. Si es válido, entonces la firma anterior se elimina y se crea un nuevo certificado.

Los ingredientes para el nuevo certificado son los siguientes:

Información de CSR (más algunos campos agregados / modificados / eliminados. Lo que su CA considere que es lo mejor).
Por lo general, algunas restricciones básicas (como la declaración: "Lo que estoy firmando aquí es (o no) se supone que es una CA.")
Información sobre quién está firmando.
Y luego la firma misma.

Todas las piezas que deben firmarse forman un conjunto. Este conjunto se llama "TBSCertificate".
Y las partes de firma TBSCertificate + conforman lo que entonces se llama "Certificado".

RFC 5280 lo desglosa de la siguiente manera:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3

    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
    }

Hay una excelente publicación en el blog que profundiza sobre qué es y qué no está realmente dentro de un certificado: Morgan Simonsen, 2013-04-16, Entendiendo las huellas digitales del certificado digital X.509 ( Archivado aquí )