Solicitud de firma de certificado

En los sistemas de infraestructura de clave pública (PKI), una solicitud de firma de certificado ( CSR o solicitud de certificación ) es un mensaje que un solicitante envía a una autoridad de certificación de la infraestructura de clave pública (PKI) para solicitar un certificado de identidad digital . La CSR generalmente contiene la clave pública para la cual se debe emitir el certificado, información de identificación (como un titular o nombre de dominio) y una prueba de posesión de la clave privada correspondiente (normalmente en forma de firma digital, que incluye protección de integridad). El formato más común para las CSR es la especificación PKCS #10 , publicada por primera vez en noviembre de 1993 ^{[ 1 ]} ; otros incluyen el formato de mensaje de solicitud de certificado (CRMF) más capaz ^{[ 2 ]} y el formato SPKAC (clave pública firmada y desafío) generado por algunos navegadores web .

Cabe destacar que ninguno de los formatos CSR autentica la identidad del solicitante. La prueba de origen de la solicitud debe obtenerse y verificarse por otros medios (normalmente mediante un protocolo de registro de certificados como CMP , EST o ACME ); de lo contrario, el certificado obtenido carece de valor de seguridad real.

Antes de crear una CSR para un certificado X.509 , el solicitante genera un par de claves , manteniendo en secreto la clave privada de ese par, por ejemplo:

$ # https://www.openssl.org/docs/manmaster/man1/openssl-genrsa.html $ # "openssl genrsa" crea una clave privada RSA: $ openssl genrsa -out 2024_wikipedia.org.key 

El CSR contiene información que identifica al solicitante (como un nombre distintivo ), la clave pública elegida por el solicitante y, posiblemente, información adicional. Al utilizar el formato PKCS #10, la solicitud debe estar autofirmada con la clave privada del solicitante , lo que proporciona una prueba de posesión (POP) de la clave privada, pero limita el uso de este formato a claves que pueden utilizarse para (algún tipo de) firma.

La solicitud de firma de certificado (CSR) debe ir acompañada de un comprobante de origen (es decir, un documento que acredite la identidad del solicitante), requisito exigido por la autoridad certificadora por motivos de seguridad. La autoridad certificadora podrá ponerse en contacto con el solicitante para solicitar información adicional.

Información típica requerida en una CSR (columna de ejemplo del certificado X.509 ). Tenga en cuenta que a menudo existen alternativas para los Nombres Distinguidos (DN); se indica el valor preferido.

Esta línea de comandos de ejemplo de OpenSSL utiliza los detalles que se enumeran en la tabla anterior para crear una CSR en formato PKCS #10:

$ # https://www.openssl.org/docs/manmaster/man1/openssl-req.html $ # "openssl req" crea una solicitud de firma de certificado en formato PKCS #10: $ openssl req -sha512 -new -subj "/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org" -key 2024_wikipedia.org.key -out 2024_wikipedia.org.csr 

La solicitud de firma de certificado (CSR) se envía normalmente a una Autoridad de Registro (AR), que verifica su contenido y autentica al solicitante. Si la verificación es exitosa, la CSR se remite a una Autoridad de Certificación (AC), que genera el certificado de clave pública X.509, lo firma digitalmente con su clave privada y envía el nuevo certificado al solicitante.

Una solicitud de certificación en formato PKCS #10 consta de tres partes principales: la información de la solicitud de certificación, un identificador del algoritmo de firma y una firma digital sobre la información de la solicitud de certificación utilizando la clave privada relacionada con la clave pública que se está certificando.

La firma constituye una autofirma con el par de claves del solicitante. Debido al requisito de autofirma, este formato solo es aplicable a tipos de claves que admiten firma. Sin embargo, existen variantes de este formato que no incluyen una firma real, como se describe en el Apéndice C.1 de RFC 5272 ( CMS ). 

La primera parte contiene, como información más importante, la clave pública y la identidad del solicitante. La autofirma del solicitante proporciona una prueba de posesión (POP). La verificación de la POP impide que una entidad solicite un certificado falso de la clave pública de otra persona. ^{[ 4 ]} Por lo tanto, se requiere la clave privada para generar una CSR PKCS #10. ^{[ 5 ]} Cabe señalar que la POP del par de claves por parte de la entidad en cuestión no proporciona ninguna autenticación de dicha entidad. Por consiguiente, la prueba de origen de la solicitud del solicitante debe proporcionarse y verificarse por otros medios. De lo contrario, se podrían generar certificados ilegítimos si la información del sujeto/titular es incorrecta.

El formulario CSR para los documentos de identidad personales y los certificados de firma suele incluir la dirección de correo electrónico del titular del documento o el nombre de la organización en el caso de documentos de identidad empresariales.

La primera parte, de tipo ASN.1 CertificationRequestInfo , consta de un número de versión (que es 0 para todas las versiones conocidas, 1.0, 1.5 y 1.7 de las especificaciones), el nombre del sujeto, la clave pública (identificador del algoritmo + cadena de bits) y un conjunto de atributos que proporcionan información adicional sobre el sujeto del certificado. Los atributos pueden contener extensiones de certificado requeridas, una contraseña de desafío para restringir las revocaciones, así como cualquier información adicional sobre el sujeto del certificado, posiblemente incluyendo tipos locales o futuros. ^{[ 4 ]}

El estándar PKCS#10 define la sintaxis, la semántica y el formato binario para las solicitudes de firma de certificado (CSR) que se utilizan con X.509 . Está codificado en ASN.1 con formato DER . A continuación, se muestra un ejemplo de cómo examinar su estructura ASN.1 utilizando OpenSSL :

openssl asn1parse -i -in your_request.p10

Un CSR puede representarse como un PKCS#10 codificado en Base64 ; a continuación se muestra un ejemplo:

-----INICIO DE LA SOLICITUD DE CERTIFICADO----- MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkVOMQ0wCwYDVQQIDARub25lMQ0wCwYD VQQHDARub25lMRIwEAYDVQQKDAlXaWtpcGVkaWExDTALBgNVBAsMBG5vbmUxGDAW BgNVBAMMDyoud2lraXBlZGlhLm9yZzEcMBoGCSqGSIb3DQEJARYNbm9uZUBub25l LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP/U8RlcCD6E8AL PT8LLUR9ygyygPCaSmIEC8zXGJung3ykElXFRz/Jc/bu0hxCxi2YDz5IjxBBOpB/ kieG83HsSmZZtR+drZIQ6vOsr/ucvpnB9z4XzKuabNGZ5ZiTSQ9L7Mx8FzvUTq5y /ArIuM+FBeuno/IV8zvwAe/VRa8i0QjFXT9vBBp35aeatdnJ2ds50yKCsHHcjvtr 9/8zPVqqmhl2XFS3Qdqlsprzbgksom67OobJGjaV+fNHNQ0o/rzP//Pl3i7vvaEG 7Ff8tQhEwR9nJUR1T6Z7ln7S6cOr23YozgWVkEJ/dSr6LAopb+cZ88FzW5NszU6i 57HhA7ECAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4IBAQBn8OCVOIx+n0AS6WbEmYDR SspR9xOCoOwYfamB+2Bpmt82R01zJ/kaqzUtZUjaGvQvAaz5lUwoMdaO0X7I5Xfl sllMFDaYoGD4Rru4s8gz2qG/QHWA8uPXzJVAj6X0olbIdLTEqTKsnBj4Zr1AJCNy /YcG4ouLJr140o26MhwBpoCRpPjAgdYMH60BYfnc4/DILxMVqR9xqK1s98d6Ob/+ 3wHFK+S7BRWrJQXcM8veAexXuk9lHQ+FgGfD0eSYGz0kyP26Qa2pLTwumjt+nBPl rfJxaLHwTQ/1988G0H35ED0f9Md5fzoKi5evU1wG5WRxdEUPyt3QUXxdQ69i0C+7 -----FIN DE LA SOLICITUD DE CERTIFICADO-----

La estructura ASN.1 DER de la solicitud de firma de certificado anterior (tal como la analiza openssl) aparece de la siguiente manera, donde el primer número es el desplazamiento de bytes, d=profundidad, hl=longitud del encabezado del tipo actual, l=longitud del contenido:

0 :d= 0 hl = 4 l= 716 cons : SECUENCIA 4 :d= 1 hl = 4 l= 436 cons : SECUENCIA 8 :d= 2 hl = 2 l= 1 prim : ENTERO : 00 11 :d= 2 hl = 3 l= 134 cons : SECUENCIA 14 :d= 3 hl = 2 l= 11 cons : CONJUNTO 16 :d= 4 hl = 2 l= 9 cons : SECUENCIA 18 :d= 5 hl = 2 l= 3 prim : OBJETO : countryName 23 :d= 5 hl = 2 l= 2 prim : CADENA IMPRIMIBLE : EN 27 :d= 3 hl = 2 l= 13 cons : CONJUNTO 29 :d= 4 hl = 2 l= 11 cons : SECUENCIA 31 :d= 5 hl = 2 l= 3 prim : OBJETO : nombreEstadoOProvincia 36 :d= 5 hl = 2 l= 4 prim : CADENA UTF8 : ninguna 42 :d= 3 hl = 2 l= 13 cons : CONJUNTO 44 :d= 4 hl = 2 l= 11 cons : SECUENCIA 46 :d= 5 hl = 2 l= 3 prim : OBJETO : nombreLocalidad 51 :d= 5 hl = 2 l= 4 prim : CADENA UTF8 : ninguna 57 :d= 3hl = 2 l= 18 cons : CONJUNTO 59 :d= 4 hl = 2 l= 16 cons : SECUENCIA 61 :d= 5 hl = 2 l= 3 prim : OBJETO : organizationName 66 :d= 5 hl = 2 l= 9 prim : UTF8STRING : Wikipedia 77 :d= 3 hl = 2 l= 13 cons : CONJUNTO 79 :d= 4 hl = 2 l= 11 cons : SECUENCIA 81 :d= 5 hl = 2 l= 3 prim : OBJETO : organizationalUnitName 86 :d= 5 hl = 2 l= 4 prim : UTF8STRING : none 92 :d= 3 hl = 2 l= 24 cons : CONJUNTO 94 :d= 4 hl = 2 l = 22 cons : SECUENCIA 96 :d = 5 hl = 2 l = 3 prim : OBJETO : commonName 101 :d = 5 hl = 2 l = 15 prim : UTF8STRING :* . wikipedia . org 118 :d = 3 hl = 2 l = 28 cons : CONJUNTO 120 :d = 4 hl = 2 l = 26 cons : SECUENCIA 122 :d = 5 hl = 2 l = 9 prim : OBJETO : emailAddress 133 :d = 5 hl = 2 l = 13 prim : IA5STRING : ninguno@ ninguno . com 148 :d= 2 hl = 4 l= 290 cons : SECUENCIA 152 :d= 3 hl = 2 l= 13 cons : SECUENCIA 154 :d= 4 hl = 2 l= 9 prim : OBJETO : rsaEncryption 165 :d= 4 hl = 2 l= 0 prim : NULO 167 :d= 3 hl = 4 l= 271 prim : CADENA DE BITS 442 :d= 2 hl = 2 l= 0 cons : cont [ 0 ] 444 :d= 1 hl = 2 l= 13 cons : SECUENCIA 446 :d= 2 hl = 2 l= 9 prim : OBJETO : md5WithRSAEncryption 457 :d= 2 hl = 2 l= 0 prim : NULL 459 :d= 1 hl = 4 l= 257 prim : CADENA DE BITS

Esto se generó al proporcionar la codificación base64 en el comando donde PEM ( Privacy-Enhanced Mail ) es la codificación de las reglas de codificación distinguida ASN.1 en base64.openssl asn1parse -in your_request.p10 -inform PEM -i