Certificate Signing Request
En los sistemas de infraestructura de clave pública (PKI), una certificate signing request (también conocida como CSR o certification request) es un mensaje enviado por un solicitante a una autoridad de registro de la infraestructura de clave pública para solicitar un certificado de identidad digital. Por lo general, contiene la clave pública para la cual se debe emitir el certificado, información de identificación (como, por ejemplo, un nombre de dominio) y protección de integridad (por ejemplo, una firma digital). El formato más común para las CSRs es la especificación PKCS #10; otro es el formato Signed Public Key and Challenge SPKAC generado por algunos navegadores web.
Procedimiento
Antes de crear una CSR, el solicitante primero genera un par de claves, manteniendo la clave privada en secreto. La CSR contiene información que identifica al solicitante (como un distinguished name en el caso de un certificado X.509) que debe firmarse con la clave privada del solicitante. La CSR también contiene la clave pública elegida por el solicitante. La CSR puede ir acompañada por otras credenciales o pruebas de identidad requeridas por la autoridad de certificación, y la autoridad de certificación puede comunicarse con el solicitante para obtener más información.
Información típica requerida en una CSR. Tener en cuenta que a menudo hay alternativas para los Distinguished Names (DN), se enumera el valor preferido.
DN[1] | Información | Descripción | Ejemplo |
---|---|---|---|
CN |
Common Name | Este es el fully qualified domain name que se desea proteger | *.wikipedia.org |
O |
Organization Name | Normalmente, el nombre legal de una empresa o entidad y debería incluir cualquier sufijo como Ltd., Inc. o Corp. | Wikimedia Foundation, Inc. |
OU |
Organizational Unit | Nombre de departamento/división de organización interno | IT |
L |
Locality | Nombre de pueblo, ciudad, etc. | San Francisco |
ST |
State | Provincia, región, condado o estado. Este no debe abreviarse (p. ej., West Sussex, Normandy, New Jersey). | California |
C |
Country | El código ISO de dos letras del país donde se encuentra la organización | US |
EMAIL |
Email Address | El contacto de la organización, generalmente del administrador del certificado o del departamento de IT. |
Si la solicitud tiene éxito, la autoridad de certificación devolverá un certificado de identidad que se ha firmado digitalmente con la clave privada de la autoridad de certificación.
Estructura
Una solicitud de certificación consta de tres partes principales: la información de la solicitud de certificación, un identificador de algoritmo de firma y una firma digital en la información de la solicitud de certificación. La primera parte contiene la información significativa, incluyendo la clave pública. La firma del solicitante evita que una entidad solicite un certificado falso de la clave pública de otra persona.[2] Por lo tanto, hay que producir la clave privada, pero no es parte de la CSR.[3]
Las CSR para certificados de ID personal y certificados de firma deben tener la dirección de email del titular del ID o el nombre de la organización en el caso de un ID comercial.
La primera parte, CertificationRequestInfo de tipo ASN.1, consta de un número de versión (que es 0 para todas las versiones conocidas de las especificaciones: 1.0, 1.5 y 1.7), el nombre del sujeto, la clave pública (identificador de algoritmo + cadena de bits), y una colección de atributos que proporcionan información adicional sobre el sujeto del certificado. Los atributos pueden contener extensiones de certificados 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.[2]
Ejemplo
El estándar PKCS#10 define un formato binario para codificar CSRs para usar con X.509. Se expresa en ASN.1. Aquí hay un ejemplo de cómo examinar su estructura ASN.1 usando OpenSSL:
openssl asn1parse -i -in your_request
Una CSR puede representarse como un PKCS#10 codificado en Base64; un ejemplo de lo cual se da a continuación:
-----BEGIN CERTIFICATE REQUEST----- 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 -----END CERTIFICATE REQUEST-----
La estructura ASN.1 de la CSR anterior (según el análisis de openssl) aparece de la siguiente manera, donde el primer número es el desplazamiento de bytes, d=profundidad, hl=longitud de cabecera del tipo actual, l=longitud del contenido:
0:d=0 hl=4 l= 716 cons: SEQUENCE 4:d=1 hl=4 l= 436 cons: SEQUENCE 8:d=2 hl=2 l= 1 prim: INTEGER :00 11:d=2 hl=3 l= 134 cons: SEQUENCE 14:d=3 hl=2 l= 11 cons: SET 16:d=4 hl=2 l= 9 cons: SEQUENCE 18:d=5 hl=2 l= 3 prim: OBJECT :countryName 23:d=5 hl=2 l= 2 prim: PRINTABLESTRING :EN 27:d=3 hl=2 l= 13 cons: SET 29:d=4 hl=2 l= 11 cons: SEQUENCE 31:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 36:d=5 hl=2 l= 4 prim: UTF8STRING :none 42:d=3 hl=2 l= 13 cons: SET 44:d=4 hl=2 l= 11 cons: SEQUENCE 46:d=5 hl=2 l= 3 prim: OBJECT :localityName 51:d=5 hl=2 l= 4 prim: UTF8STRING :none 57:d=3 hl=2 l= 18 cons: SET 59:d=4 hl=2 l= 16 cons: SEQUENCE 61:d=5 hl=2 l= 3 prim: OBJECT :organizationName 66:d=5 hl=2 l= 9 prim: UTF8STRING :Wikipedia 77:d=3 hl=2 l= 13 cons: SET 79:d=4 hl=2 l= 11 cons: SEQUENCE 81:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName 86:d=5 hl=2 l= 4 prim: UTF8STRING :none 92:d=3 hl=2 l= 24 cons: SET 94:d=4 hl=2 l= 22 cons: SEQUENCE 96:d=5 hl=2 l= 3 prim: OBJECT :commonName 101:d=5 hl=2 l= 15 prim: UTF8STRING :*.wikipedia.org 118:d=3 hl=2 l= 28 cons: SET 120:d=4 hl=2 l= 26 cons: SEQUENCE 122:d=5 hl=2 l= 9 prim: OBJECT :emailAddress 133:d=5 hl=2 l= 13 prim: IA5STRING :none@none.com 148:d=2 hl=4 l= 290 cons: SEQUENCE 152:d=3 hl=2 l= 13 cons: SEQUENCE 154:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 165:d=4 hl=2 l= 0 prim: NULL 167:d=3 hl=4 l= 271 prim: BIT STRING 442:d=2 hl=2 l= 0 cons: cont [ 0 ] 444:d=1 hl=2 l= 13 cons: SEQUENCE 446:d=2 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption 457:d=2 hl=2 l= 0 prim: NULL 459:d=1 hl=4 l= 257 prim: BIT STRING
Esto se generó al proporcionar la codificación base64 en el comando openssl asn1parse -in your_request -inform PEM -i
donde PEM significa Privacy-Enhanced Mail y describe la codificación de las Distinguished Encoding Rules de ASN.1 en base64.
Véase también
- SPKAC
- X.509
Referencias
- «Distinguished Names». WebSphere MQ Security Concepts and mechanisms. IBM. 5 de noviembre de 2019. Consultado el 16 de enero de 2020.
- RFC 2986 - PKCS #10: Certification Request Syntax Specification Version 1.7
- Nikos Mavrogiannopoulos (9 de enero de 2020). «PKCS #10 certificate requests». GnuTLS. Consultado el 16 de enero de 2020.