Certificate signing request

In public key infrastructure systems, a certificate signing request is a message sent from an applicant to a certificate authority of the public key infrastructure in order to apply for a digital identity certificate. The CSR usually contains the public key for which the certificate should be issued, identifying information and a proof of possession of the corresponding private key. The most common format for CSRs is the PKCS #10 specification; others include the more capable Certificate Request Message Format and the SPKAC format generated by some web browsers.
Note that neither of the CSR formats authenticate the identity of the requester. The proof of origin of the request must be achieved and verified by other means, otherwise the obtained certificate has no real security value.

Procedure

Before creating a CSR for an X.509 certificate, the applicant generates a key pair, keeping the private key of that pair secret, e.g.:
The CSR contains information identifying the applicant, the public key chosen by the applicant, and possibly further information. When using the PKCS #10 format, the request must be self-signed using the applicant's private key, which provides proof of possession of the private key but limits the use of this format to keys that can be used for signing.
The CSR must be accompanied by a proof of origin, which is required for security reasons by the certificate authority. The certificate authority may contact the applicant for further information.
Typical information required in a CSR. Note that there are often alternatives for the Distinguished Names, the preferred value is listed.

DN	Information	Description	Sample
`CN`	Common Name	This is fully qualified domain name that you wish to secure	*.wikipedia.org
`O`	Organization Name	Usually the legal name of a company or entity and should include any suffixes such as Ltd., Inc., or Corp.	Wikimedia Foundation, Inc.
`OU`	Organizational Unit	Internal organization department/division name	IT
`L`	Locality	Town, city, village, etc. name	San Francisco
`ST`	State	Province, region, county or state. This should not be abbreviated.	California
`C`	Country	The two-letter ISO code for the country where your organization is located	US
`emailAddress`	Email Address	The organization contact, usually of the certificate administrator or IT department

This OpenSSL sample command line uses the details as listed in the table above to create a CSR in PKCS #10 format:
The CSR is typically sent to a Registration Authority, which checks the CSR contents and authenticates the applicant.
On success the CSR is forwarded to a Certificate Authority, which produces the X.509 public-key certificate, digitally signing it using the CA private key, and sends the new certificate to the applicant.

Structure of a PKCS #10 CSR

A certification request in PKCS #10 format consists of three main parts: the certification request information, a signature algorithm identifier, and a digital signature on the certification request information using the private key related to the public key being certified.
The signature constitutes a self-signature with the key pair of the applicant.
Due to the self-signature requirement, this format is
applicable only to types of keys that support signing.
Yet there are variants of this format that do not include an actual
signature, such as described in Appendix C.1 of .
The first part contains as its most significant information the public key and the identity of the applicant. The self-signature by the applicant provides a proof of possession. Checking the POP prevents an entity from requesting a bogus certificate of someone else's public key. Thus the private key is required to produce a PKCS #10 CSR.
Yet note that the POP for the key pair by the subject entity
does not provide any authentication of the subject entity.
The proof of origin for the request by the applicant must therefore be provided and checked by other means.
Otherwise illegitimate certificates can be produced where the subject/holder information is wrong.
CSR for personal ID certificates and signing certificates usually includes the email address of the ID holder or the name of organisation in case of business ID.
The first part, ASN.1 type CertificationRequestInfo, consists of a version number, the subject name, the public key, 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.

Example of a PKCS #10 CSR

The PKCS#10 standard defines syntax, semantics, and binary format for CSRs for use with X.509. It is encoded in ASN.1 with DER format. Here is an example of how you can examine its ASN.1 structure using OpenSSL:
openssl asn1parse -i -in your_request.p10
A CSR may be represented as a Base64 encoded PKCS#10; an example of which is
given below:
The above certificate signing request's ASN.1 DER structure 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
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.p10 -inform PEM -i where PEM is the encoding of the ASN.1 Distinguished Encoding Rules in base64.