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
[editar]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
[editar]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
[editar]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
[editar]Referencias
[editar]- ↑ «Distinguished Names». WebSphere MQ Security Concepts and mechanisms. IBM. 5 de noviembre de 2019. Consultado el 16 de enero de 2020.
- ↑ a b 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.