Certificate Signing Request

De Wikipedia, la enciclopedia libre

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]

  1. «Distinguished Names». WebSphere MQ Security Concepts and mechanisms. IBM. 5 de noviembre de 2019. Consultado el 16 de enero de 2020. 
  2. a b RFC 2986 - PKCS #10: Certification Request Syntax Specification Version 1.7
  3. Nikos Mavrogiannopoulos (9 de enero de 2020). «PKCS #10 certificate requests». GnuTLS. Consultado el 16 de enero de 2020.