Certificate signing request

In public key infrastructure (PKI) systems, a certificate signing request (also CSR or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. It usually contains the public key for which the certificate should be issued, identifying information (such as a domain name) and integrity protection (e.g., a digital signature). The most common format for CSRs is the PKCS #10 specification; another is the Signed Public Key and Challenge SPKAC format generated by some web browsers.

Procedure

Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate) which must be signed using the applicant's private key. The CSR also contains the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information.

Typical information required in a CSR (sample column from sample X.509 certificate). Note that there are often alternatives for the Distinguished Names (DN), the preferred value is listed.

DN[1] Information Description Sample
CN Common Name This is fully qualified domain name that you wish to secure *.wikipedia.org
O Business name / Organization Usually the legal incorporated name of a company and should include any suffixes such as Ltd., Inc., or Corp. Wikimedia Foundation, Inc.
OU Department Name / Organizational Unit e.g. HR, Finance, IT
L Town / City San Francisco
ST Province, Region, County or State This should not be abbreviated e.g. West Sussex, Normandy, New Jersey California
C Country The two-letter ISO code for the country where your organization is located US
MAIL Email address The organization contact, usually of the certificate administrator or IT department

If the request is successful, the certificate authority will send back an identity certificate that has been digitally signed using the private key of the certificate authority.

Structure

A certification request consists of three main parts: the certification request information, a signature algorithm identifier, and a digital signature on the certification request information. The first part contains the significant information, including the public key. The signature by the requester prevents an entity from requesting a bogus certificate of someone else's public key.[2] Thus the private key is needed to produce, but it is not part of, the CSR.[3]

CSR for personal ID certificates and signing certificates must have the email address of the ID holder or name of organisation in case of business ID.

The first part, ASN.1 type CertificationRequestInfo, consists of a version number (which is 0 for all known versions, 1.0, 1.5, and 1.7 of the specifications), the subject name, the public key (algorithm identifier + bit string), and a collection of attributes providing additional information about the subject of the certificate. The attributes can contain required certificate extensions, a challenge-password to restrict revocations, as well as any additional information about the subject of the certificate, possibly including local or future types.[2]

Example

The PKCS#10 standard defines a binary format for encoding CSRs for use with X.509. It is expressed in ASN.1. Here is an example of how you can examine its ASN.1 structure using OpenSSL:

openssl asn1parse -i -in your_request

A CSR may be represented as a Base64 encoded PKCS#10; an example of which is given below:

-----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-----

The above certificate signing request's ASN.1 structure (as parsed by openssl) appears as the following, where the first number is the byte offset, d=depth, hl=header length of the current type, l=length of content:

    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        

This was generated by supplying the base64 encoding into the command openssl asn1parse -in your_request -inform PEM -i where PEM stands for Privacy-Enhanced Mail and describes the encoding of the ASN.1 Distinguished Encoding Rules in base64.

gollark: I did do geography for a while (pre-GCSEs), but it wasn't grouped in with the science stuff. I've also completely forgotten what we did, so very effective teaching right there.
gollark: Ah.
gollark: Wait, you do geology as one of your core science things? Weird.
gollark: So just anti-new-things indoctrination, how wonderful.
gollark: The closest thing to ethics we did was philosophy for something like six hours a year due to weird timetabling, which actually was pretty good.

See also

References

  1. "Distinguished Names". WebSphere MQ Security Concepts and mechanisms. IBM. 2019-11-05. Retrieved 2020-01-16.
  2. RFC 2986 - PKCS #10: Certification Request Syntax Specification Version 1.7
  3. Nikos Mavrogiannopoulos (2020-01-09). "PKCS #10 certificate requests". GnuTLS. Retrieved 2020-01-16.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.