Reference articles on history, science, culture and more
Encyclopedia

Certificate signing request

Message sent to a certificate authority to apply for a certificate

In public key infrastructure (PKI) systems, a certificate signing request (CSR or certification request) is a message sent from an applicant to a certificate authority of the public key infrastructure (PKI) 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 (such as a holder or domain name) and a proof of possession of the corresponding private key (typically in the form of a digital signature, which includes integrity protection). The most common format for CSRs is the PKCS #10 specification, first published in November 1993; others include the more capable Certificate Request Message Format (CRMF) and the SPKAC (Signed Public Key and Challenge) 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 (typically using a certificate enrollment protocol such as CMP, EST, or ACME), otherwise the obtained certificate has no real security value.

01Procedure

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

$ # https://www.openssl.org/docs/manmaster/man1/openssl-genrsa.html $ # "openssl genrsa" creates an RSA private key: $ openssl genrsa -out 2024_wikipedia.org.key

The CSR contains information identifying the applicant (such as a distinguished name), 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 (POP) of the private key but limits the use of this format to keys that can be used for (some form of) signing.

The CSR must be accompanied by a proof of origin (i.e., proof of identity of the applicant), 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 (sample column from sample X.509 certificate). Note that there are often alternatives for the Distinguished Names (DN), 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 (e.g. West Sussex, Normandy, New Jersey). 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:

$ # https://www.openssl.org/docs/manmaster/man1/openssl-req.html $ # "openssl req" creates a certificate signing request in PKCS #10 format: $ openssl req -sha512 -new -subj "/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org" -key 2024_wikipedia.org.key -out 2024_wikipedia.org.csr

The CSR is typically sent to a Registration Authority (RA), which checks the CSR contents and authenticates the applicant. On success the CSR is forwarded to a Certificate Authority (CA), which produces the X.509 public-key certificate, digitally signing it using the CA private key, and sends the new certificate to the applicant.

02Structure 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 RFC 5272 (CMS).

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 (POP). 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 (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.

03Example 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:

-----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 DER 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.p10 -inform PEM -i where PEM (Privacy-Enhanced Mail) is the encoding of the ASN.1 Distinguished Encoding Rules in base64.

Watch videos about Certificate signing requestExplainers and documentaries on YouTube (opens in a new tab)

Sources and credits

This article is adapted from the Wikipedia article Certificate signing request, written by its contributors and licensed under CC BY-SA 4.0. Fathomly has changed the layout, removed citation markers, navigation and maintenance notices, and adjusted punctuation. This adapted version is shared under the same license. For references, see the original article.

Fathomly is not affiliated with or endorsed by the Wikimedia Foundation. Spotted a problem? Tell us.