Certificate signing request

Last updated

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 domain name) and a proof of authenticity including integrity protection (e.g., a digital signature). The most common format for CSRs is the PKCS #10 specification; others include the more capable Certificate Request Message Format (CRMF) [1] and the SPKAC (Signed Public Key and Challenge) format generated by some web browsers.

Contents

Procedure

Before creating a CSR for an X.509 certificate, the applicant first 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 of the private key but limits the use of this format to keys that can be used for (some form of) signing. The CSR should be accompanied by a proof of origin (i.e., proof of identity of the applicant) that is 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 [2] InformationDescriptionSample
CNCommon NameThis is fully qualified domain name that you wish to secure*.wikipedia.org
OOrganization NameUsually the legal name of a company or entity and should include any suffixes such as Ltd., Inc., or Corp.Wikimedia Foundation, Inc.
OUOrganizational UnitInternal organization department/division nameIT
LLocalityTown, city, village, etc. nameSan Francisco
STStateProvince, region, county or state. This should not be abbreviated (e.g. West Sussex, Normandy, New Jersey).California
CCountryThe two-letter ISO code for the country where your organization is locatedUS
EMAILEmail AddressThe organization contact, usually of the certificate administrator or IT department

This sample command line uses the details as listed in the table above:

 # https://www.openssl.org/docs/manmaster/man1/openssl-req.html # "openssl req" creates a signing request:  $ 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 


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 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. 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. [3] Thus the private key is needed to produce a PKCS #10 CSR, but it is not part of, the CSR. [4]

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. [3]

Example of a PKCS #10 CSR

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

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

-----BEGIN CERTIFICATE REQUEST-----MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkVOMQ0wCwYDVQQIDARub25lMQ0wCwYDVQQHDARub25lMRIwEAYDVQQKDAlXaWtpcGVkaWExDTALBgNVBAsMBG5vbmUxGDAWBgNVBAMMDyoud2lraXBlZGlhLm9yZzEcMBoGCSqGSIb3DQEJARYNbm9uZUBub25lLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP/U8RlcCD6E8ALPT8LLUR9ygyygPCaSmIEC8zXGJung3ykElXFRz/Jc/bu0hxCxi2YDz5IjxBBOpB/kieG83HsSmZZtR+drZIQ6vOsr/ucvpnB9z4XzKuabNGZ5ZiTSQ9L7Mx8FzvUTq5y/ArIuM+FBeuno/IV8zvwAe/VRa8i0QjFXT9vBBp35aeatdnJ2ds50yKCsHHcjvtr9/8zPVqqmhl2XFS3Qdqlsprzbgksom67OobJGjaV+fNHNQ0o/rzP//Pl3i7vvaEG7Ff8tQhEwR9nJUR1T6Z7ln7S6cOr23YozgWVkEJ/dSr6LAopb+cZ88FzW5NszU6i57HhA7ECAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4IBAQBn8OCVOIx+n0AS6WbEmYDRSspR9xOCoOwYfamB+2Bpmt82R01zJ/kaqzUtZUjaGvQvAaz5lUwoMdaO0X7I5XflsllMFDaYoGD4Rru4s8gz2qG/QHWA8uPXzJVAj6X0olbIdLTEqTKsnBj4Zr1AJCNy/YcG4ouLJr140o26MhwBpoCRpPjAgdYMH60BYfnc4/DILxMVqR9xqK1s98d6Ob/+3wHFK+S7BRWrJQXcM8veAexXuk9lHQ+FgGfD0eSYGz0kyP26Qa2pLTwumjt+nBPlrfJxaLHwTQ/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.p10 -inform PEM -i where PEM (Privacy-Enhanced Mail) is the encoding of the ASN.1 Distinguished Encoding Rules in base64.

Related Research Articles

In computer programming, Base64 is a group of binary-to-text encoding schemes that transforms binary data into a sequence of printable characters, limited to a set of 64 unique characters. More specifically, the source binary data is taken 6 bits at a time, then this group of 6 bits is mapped to one of 64 unique characters.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

UTF-7 is an obsolete variable-length character encoding for representing Unicode text using a stream of ASCII characters. It was originally intended to provide a means of encoding Unicode text for use in Internet E-mail messages that was more efficient than the combination of UTF-8 with quoted-printable.

<span class="mw-page-title-main">OpenSSL</span> Open-source implementation of the SSL and TLS protocols

OpenSSL is a software library for applications that provide secure communications over computer networks against eavesdropping, and identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

Privacy-Enhanced Mail (PEM) is a de facto file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 IETF standards defining "privacy-enhanced mail." While the original standards were never broadly adopted and were supplanted by PGP and S/MIME, the textual encoding they defined became very popular. The PEM format was eventually formalized by the IETF in RFC 7468.

In cryptography, PKCS are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards, some of the standards have begun to move into the "standards track" processes of relevant standards organizations in recent years, such as the IETF and the PKIX working group.

T.61 is an ITU-T Recommendation for a Teletex character set. T.61 predated Unicode, and was the primary character set in ASN.1 used in early versions of X.500 and X.509 for encoding strings containing characters used in Western European languages. It is also used by older versions of LDAP. While T.61 continues to be supported in modern versions of X.500 and X.509, it has been deprecated in favor of Unicode. It is also called Code page 1036, CP1036, or IBM 01036.

The data URI scheme is a uniform resource identifier (URI) scheme that provides a way to include data in-line in Web pages as if they were external resources. It is a form of file literal or here document. This technique allows normally separate elements such as images and style sheets to be fetched in a single Hypertext Transfer Protocol (HTTP) request, which may be more efficient than multiple HTTP requests, and used by several browser extensions to package images as well as other multimedia content in a single HTML file for page saving. As of 2024, data URIs are fully supported by all major browsers.

A binary-to-text encoding is encoding of data in plain text. More precisely, it is an encoding of binary data in a sequence of printable characters. These encodings are necessary for transmission of data when the communication channel does not allow binary data or is not 8-bit clean. PGP documentation uses the term "ASCII armor" for binary-to-text encoding when referring to Base64.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

A Canonical S-expression is a binary encoding form of a subset of general S-expression. It was designed for use in SPKI to retain the power of S-expressions and ensure canonical form for applications such as digital signatures while achieving the compactness of a binary form and maximizing the speed of parsing.

Simple Certificate Enrollment Protocol (SCEP) is described by the informational RFC 8894. Older versions of this protocol became a de facto industrial standard for pragmatic provisioning of digital certificates mostly for network equipment.

In cryptography, PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.

ASN.1 Information Object Class is a concept widely used in ASN.1 specifications to address issues related to protocol specification similar to issues addressed by CORBA/IDL specifications.

<span class="mw-page-title-main">Key Management Interoperability Protocol</span> Communication protocol for the manipulation of cryptographic keys

The Key Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. This facilitates data encryption by simplifying encryption key management. Keys may be created on a server and then retrieved, possibly wrapped by other keys. Both symmetric and asymmetric keys are supported, including the ability to sign certificates. KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.

A Digital Cinema Package (DCP) is a collection of digital files used to store and convey digital cinema (DC) audio, image, and data streams.

wolfSSL is a small, portable, embedded SSL/TLS library targeted for use by embedded systems developers. It is an open source implementation of TLS written in the C programming language. It includes SSL/TLS client libraries and an SSL/TLS server implementation as well as support for multiple APIs, including those defined by SSL and TLS. wolfSSL also includes an OpenSSL compatibility interface with the most commonly used OpenSSL functions.

X.690 is an ITU-T standard specifying several ASN.1 encoding formats:

In cryptography, PKCS #8 is a standard syntax for storing private key information. PKCS #8 is one of the family of standards called Public-Key Cryptography Standards (PKCS) created by RSA Laboratories. The latest version, 1.2, is available as RFC 5208.

In cryptography, PKCS #7 is a standard syntax for storing signed and/or encrypted data. PKCS #7 is one of the family of standards called Public-Key Cryptography Standards (PKCS) created by RSA Laboratories.

References

  1. "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)".
  2. "Distinguished Names". WebSphere MQ Security Concepts and mechanisms. IBM. 2019-11-05. Retrieved 2020-01-16.
  3. 1 2 RFC   2986 - PKCS #10: Certification Request Syntax Specification Version 1.7
  4. Nikos Mavrogiannopoulos (2020-01-09). "PKCS #10 certificate requests". GnuTLS . Retrieved 2020-01-16.