¿Es la clave privada la única entropía en un certificado X509?

Como se describe en RFC 5280 , un certificado tiene la siguiente estructura general:

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

Los tres elementos son el "por firmar", un identificador para el algoritmo de firma y la firma. Si desea poder regenerar exactamente el mismo certificado, entonces los tres elementos deben reconstruirse de manera idéntica.

La mayoría de los certificados en circulación usan firmas RSA "v1.5", como se describe en PKCS # 1 . Ese algoritmo de firma es determinista, por lo que si usa la misma clave privada, los mismos parámetros de algoritmo (la función de hash complementaria) y la misma entrada (la que debe firmarse), obtendrá la misma firma. Lo mismo NO es válido para el esquema de firma "PSS" más nuevo y elegante descrito en PKCS # 1; ese es aleatorio y obtendrá un valor de firma distinto cada vez. De manera similar, si el tipo de clave es DSA o ECDSA, entonces el esquema de firma correspondiente es aleatorio, a menos que use una implementación determinista específica (lo cual es posible pero no dado).

Suponiendo que utiliza un esquema de firma determinista , entonces la pregunta se reduce a reproducir el mismo contenido que se debe firmar. La firma a firmar contiene lo siguiente:

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
    }

La mayoría de las bibliotecas que crean "certificados autofirmados" introducirán variaciones en los campos serialNumber (dado que se supone que el número de serie es único, a menudo se generarán al azar) y los campos validity . El validity contiene las dos fechas que delimitan el rango de tiempo de validez del certificado; por lo general, una biblioteca que crea un certificado autofirmado usará la fecha y la hora actuales para la primera fecha y, por lo tanto, no usará el mismo valor si el certificado se vuelve a crear más adelante.

Las extensiones son, por definición, abiertas, y pueden contener varios elementos aleatorios también.

Los certificados autofirmados , por definición, NO son certificados; viven fuera del proceso de validación de certificados, y ese proceso es la única razón por la cual los certificados realmente existen. Un certificado autofirmado es un nombre y una clave pública, codificados juntos en lo que parece superficialmente un certificado de una mezcla de reutilización rápida y sucia de código existente, Tradición de larga data y confusión histórica. Dicho "certificado" es autofirmado porque hay un campo no opcional para una firma, pero esa firma no tiene sentido.

Por lo tanto, en un certificado autofirmado, la mayoría, si no todas, las "extensiones" se ignorarán, al igual que algunos otros campos, como el número de serie. Probablemente puede (dependiendo de lo que requiera su protocolo de servidor a servidor en estos "certificados") rellenar los campos con valores fijos, falsos que harán feliz a su protocolo, y pueden ser rellenados de manera idéntica más adelante. Sin embargo, no todas las bibliotecas de soporte existentes lo permitirán; es posible que tenga que volver a escribir su propio codificador de certificado (que es factible pero al precio de su cordura ).

Es necesario guardar más que solo la clave privada para reproducir el certificado.

Debería poder crear una Solicitud de firma de certificado (CSR) que contendrá la mayor parte de la información necesaria, además de la clave privada.

Sin embargo, dado que hay datos en el certificado que no se deben duplicar en otros certificados (por ejemplo, el número de serie), debe tener control sobre la autoridad de firma y estar dispuesto a romper las reglas.