1 Purpose and role
A certificate signing request is the standard message used to ask a certificate authority to issue a digital certificate. It packages the information needed to identify the requester and to bind that identity to a public key. The request is usually created by the entity that will hold the certificate, then submitted to a trusted issuer for review and signing.
CSRs are an important part of public key infrastructure because they begin the certificate lifecycle. They help separate the generation of key material from the act of certificate issuance, allowing the applicant to demonstrate control of the corresponding private key while the authority decides whether the request meets its policies.
1.1 Certificate issuance workflow
In a typical workflow, the applicant first creates a private key and the matching public key. A CSR is then generated from that key pair and includes the information the applicant wants carried into the certificate, such as a subject name and requested extensions. The CSR is sent to a certificate authority, which checks the request and, if approved, signs a certificate based on it.
This process is used not only for initial issuance but also for renewal and rekeying. In a renewal, a new certificate may be requested for an existing service, while rekeying usually involves creating a fresh key pair and new request. The CSR provides a standardized starting point for each of these actions.
1.2 Relationship to public key infrastructure
Within public key infrastructure, a CSR functions as the formal request component of certificate management. It is not itself a certificate and does not grant trust on its own. Instead, it supplies the authority with the data needed to issue a certificate that can later be validated by relying parties.
Because the request is signed with the applicant’s private key, it also serves as evidence that the requester possesses the corresponding key. That proof of possession is central to PKI procedures, since it helps prevent certificates from being issued for keys the applicant does not control.
1.3 Uses in SSL/TLS and other certificates
CSRs are most widely associated with SSL/TLS certificates used to secure websites and other network services. In that setting, the request commonly includes the domain name or names that the certificate should cover. After issuance, the certificate is installed on a server or service to enable encrypted connections and identity verification.
The same mechanism is used for many other certificate types, including code signing, email protection, document signing, and device authentication. Although the exact fields and approval rules vary, the CSR remains the common request format for initiating certificate issuance.
2 Structure of a certificate signing request
A CSR is built from several core elements. These include the public key, identifying subject data, a signature over the request, and optional extensions or attributes. Together, these elements tell the certificate authority what the applicant is asking for and provide a means to verify the request’s integrity.
The precise internal structure depends on the encoding standard used, but the logical content is similar across implementations. Most CSRs are designed so that the requested information can be checked, approved, and translated into a final certificate with minimal ambiguity.
2.1 Public key information
The public key is the central cryptographic component of the request. It identifies the key that will later correspond to the issued certificate and is the key that other parties will use to verify signatures or establish secure communication. The request generally includes the algorithm type and key parameters as part of the public key data.
The strength and suitability of the certificate depend heavily on this key material. A certificate authority may reject requests that use obsolete or insufficiently strong algorithms, or keys that do not match the intended certificate profile.
2.2 Subject distinguished name
The subject distinguished name is the identifying label associated with the requester. It can contain fields such as common name, organization, organizational unit, locality, state or province, and country. In some certificate profiles, only a subset of these fields is used, while others are treated as optional or ignored.
This name is intended to identify the entity that will use the certificate, though modern certificates often rely more heavily on subject alternative name entries for specific identifiers such as domain names. Even so, the subject distinguished name remains a conventional part of the CSR structure.
2.3 Signature and hash algorithm
A CSR is signed by the applicant using the private key associated with the included public key. The signature covers the request data so that any alteration can be detected. A hash algorithm is used as part of the signing process, and the signature algorithm identifies the cryptographic method employed.
The signature has two main purposes. First, it proves possession of the private key. Second, it protects the integrity of the submitted request, giving the certificate authority confidence that the public key and requested fields have not been changed in transit.
2.4 Extensions and attributes
Many CSRs include optional attributes or extension requests that describe how the eventual certificate should be used. These can influence the contents of the final certificate, although the issuing authority may modify or ignore them according to policy. Extensions help tailor the certificate for a specific role without changing the underlying key pair.
2.4.1 Subject alternative name
The subject alternative name extension lists additional identities that the certificate should cover. For web certificates, this often includes one or more domain names, and it may also include IP addresses or other identifiers in appropriate contexts. In modern practice, this field is often more important than the subject common name.
When a CSR requests a subject alternative name, the certificate authority may verify each entry according to its issuance rules. The final certificate will only include approved values.
2.4.2 Key usage constraints
Key usage information limits the cryptographic operations for which the certificate may be used. Examples include digital signature, key encipherment, and certificate signing. These constraints help define the certificate’s intended role and reduce misuse.
A certificate authority may accept a requested key usage profile, adjust it, or impose its own restrictions. The final certificate should reflect the operational purpose for which it was issued.
2.4.3 Extended key usage
Extended key usage specifies more detailed application purposes for the certificate. Common examples include server authentication, client authentication, code signing, and email protection. This field adds another layer of control beyond basic key usage.
In a CSR, extended key usage may be requested to indicate the planned deployment of the certificate. The authority decides whether the request is appropriate and whether those usages should appear in the issued certificate.
3 Request generation
Creating a CSR begins with generating a private key and then producing the request from that key and the desired subject information. The exact steps vary by tool and platform, but the underlying process is consistent: create key material, assemble request data, and sign the request with the private key.
Administrators often generate CSRs on the same system where the certificate will later be deployed, especially for server certificates. In other cases, the request is created in a secure environment and then transferred to the certificate authority through a separate enrollment process.
3.1 Creating a private key
The private key is created before the CSR and should remain confidential throughout its lifetime. Its corresponding public key is embedded in the request. Key generation choices include algorithm type, such as RSA or elliptic curve algorithms, and key size or curve selection.
The security of the resulting certificate depends on the private key remaining protected. If the key is exposed, an attacker could misuse the certificate or impersonate the legitimate holder, even if the certificate itself was properly issued.
3.2 Generating the CSR
After the private key exists, the CSR is generated by combining the public key with identifying information and optional extensions. The resulting request is then signed with the private key. This signature creates a cryptographic link between the request and the key holder.
The request can be generated interactively, through automated scripts, or by management systems that integrate with certificate enrollment workflows. Automation is common in large environments where certificates must be renewed frequently and consistently.
3.3 Command-line tools and libraries
A variety of tools and software libraries can create and process CSRs. Command-line utilities are common in administration tasks, while programming libraries are used in applications, deployment systems, and enrollment services. The choice of tool usually depends on platform, policy, and operational scale.
3.3.1 OpenSSL
OpenSSL is one of the most widely used tools for generating CSRs. It supports many key algorithms, request attributes, and output formats. Administrators often use it in manual certificate workflows because it is flexible and broadly available.
Although powerful, OpenSSL requires careful parameter selection. Mistakes in subject data, extensions, or key generation can lead to requests that must be regenerated.
3.3.2 Platform-specific tools
Many operating systems and certificate management platforms provide their own request generation tools. These may offer graphical interfaces, integrated key storage, or built-in enrollment with a local authority. Such tools can simplify CSR creation for users who do not work directly with command-line utilities.
Platform-specific tools are especially useful when certificate management is tied to a broader system, such as a server management console or a device enrollment framework. They often guide the user through the required fields and reduce the chance of formatting errors.
4 CSR formats and encoding
CSRs are encoded using standard data formats so they can be stored, transmitted, and parsed consistently. The most common encodings are PEM and DER, both of which represent the same underlying request data in different forms. Some systems also display CSRs as plain base64 text within a recognizable wrapper.
Format compatibility matters because certificate authorities and management systems may expect a specific representation. Converting between formats is common, especially when copying requests between tools or submitting them through web interfaces.
4.1 PEM encoding
PEM encoding wraps the request in readable header and footer lines surrounding base64 text. This format is widely used in configuration files, email, documentation, and web interfaces because it is easy to copy and paste. The encoded content remains a textual representation of the binary request.
PEM is often the most familiar CSR format to administrators. It is convenient for manual handling, though it still contains cryptographically meaningful data and should be treated carefully.
4.2 DER encoding
DER is a binary encoding of the CSR. It is compact and precise, making it useful for systems that prefer machine-readable, unambiguous structures. Many software components can convert between DER and PEM as needed.
Because DER is binary, it is less suitable for direct editing or casual viewing. Its main advantage is strictness and efficiency in automated processing.
4.3 Base64 representation
Base64 is the text encoding used within PEM and sometimes presented on its own by enrollment systems. It translates binary data into printable characters, making the request easier to move through text-based channels. When base64 appears with PEM headers, it is still part of a structured CSR rather than a standalone token.
This representation is practical for submission forms and copyable messages. However, the presence of base64 does not change the request’s underlying cryptographic content.
5 Submission and validation
Once generated, the CSR is submitted to a certificate authority or an automated enrollment service. The submission may happen through a portal, an API, an enrollment protocol, or direct administrative handling. After receipt, the request is examined for authenticity, policy compliance, and correctness.
Validation steps are important because the certificate authority must ensure that the request is legitimate and that the resulting certificate will contain accurate information. The review process varies in strictness depending on certificate type and issuer policy.
5.1 Sending the CSR to a certificate authority
The CSR is transmitted to the certificate authority in the format expected by the enrollment channel. In some systems, the request is uploaded manually; in others, it is sent automatically as part of a managed certificate workflow. The authority uses the request as the basis for deciding whether to issue a certificate.
The applicant usually also provides any supporting documentation required by the issuer, particularly when identity verification is involved. For many automated domain-validation certificates, this supporting process is integrated into the approval workflow.
5.2 Verification of proof of possession
A key validation step is proof of possession. Because the CSR is signed with the private key associated with the included public key, the authority can check that the requester holds that private key. If the signature verifies, the authority knows the request was generated by someone with access to the corresponding secret key.
This verification does not by itself establish the requester’s real-world identity. It simply confirms control of the key pair. Additional checks may still be required before a certificate can be issued.
5.3 Approval and policy checks
Beyond cryptographic verification, the certificate authority applies policy rules to the request. These can include allowed key types, minimum key sizes, permitted names, extension limits, and the certificate class being requested. The authority may also compare the subject data against enrollment records or administrative approvals.
If the CSR does not meet policy requirements, the request may be declined or returned for correction. When it passes review, the authority proceeds to certificate issuance.
6 Certificate issuance
Certificate issuance is the process by which the certificate authority transforms an approved CSR into a signed certificate. The certificate contains many of the same fields as the request, but it is now digitally signed by the authority and recognized by relying parties according to the trust chain.
The issued certificate is the artifact used in practice. The CSR itself is mainly a request document and usually has no standalone operational role after issuance, except for recordkeeping or renewal purposes.
6.1 Signing by the certificate authority
After approval, the authority signs a certificate that binds the requester’s public key to the approved identity information. This signature is made using the authority’s own private key, establishing the trust relationship between the certificate and the issuing CA.
The CA signature allows clients and services to verify that the certificate was issued by a trusted entity and that it has not been altered. This is the basis for the trust model used in secure communications and other certificate-based systems.
6.2 Certificate contents derived from the CSR
Many fields in the final certificate are copied or adapted from the CSR. These commonly include the public key, subject information, and approved extensions such as subject alternative names or usage constraints. Some values may be reformatted or normalized by the authority before signing.
The issuing authority may also add data that was not explicitly present in the request, such as validity dates, serial numbers, issuer information, and policy identifiers. As a result, the certificate is related to the CSR but is not merely a direct duplicate of it.
6.3 Issuance of end-entity certificates
Most CSRs result in end-entity certificates, which are certificates used by servers, users, devices, or software rather than by a certificate authority. These certificates occupy the operational layer of the PKI hierarchy and are typically the ones installed for authentication or encryption.
End-entity issuance is the most common outcome of CSR processing. The request helps produce a certificate that can be deployed in a real-world service, while the CA retains responsibility for trust and policy enforcement.
7 CSR lifecycle and management
CSRs are part of a broader certificate management cycle. They may be created for initial enrollment, later reused as templates for similar systems, or archived as documentation of what was requested and approved. Managing them carefully helps organizations keep track of certificate deployments over time.
Lifecycle practices become especially important when certificates are renewed, replaced, or rotated. Good recordkeeping supports troubleshooting, audit trails, and continuity of service.
7.1 Renewal and rekeying
During renewal, a new CSR may be created to request another certificate before the current one expires. Some organizations keep the same key pair for renewal, while others choose to rekey and generate a fresh pair for improved security. Rekeying changes the cryptographic foundation of the certificate while preserving the service identity.
The choice between renewal and rekeying depends on policy, risk tolerance, and operational convenience. Replacing keys regularly can limit exposure if a private key is compromised or suspected to be weak.
7.2 Revocation and replacement
If a certificate must be revoked, a new CSR may be prepared to obtain a replacement certificate. Revocation can occur for many reasons, including key compromise, accidental disclosure, or changes in the certificate’s required attributes. The replacement certificate is then issued through the usual request-and-approval process.
A revoked certificate should no longer be relied upon, even if its CSR remains stored for historical reference. Replacement workflows help restore secure operation with updated credentials.
7.3 Storage and archival
Organizations often archive CSRs along with related records such as certificate serial numbers, issuance dates, and key management logs. Archived requests can be useful for audits, troubleshooting, and future renewals. They may also help confirm which names or extensions were originally requested.
Because CSRs contain public information and request metadata, they are less sensitive than private keys. Even so, they can reveal organizational details that should still be handled according to normal records-management practices.
8 Security considerations
Although a CSR is not secret in the same way as a private key, it still carries security implications. The quality of key generation, the accuracy of submitted identity data, and the choice of algorithms all influence the safety and reliability of the resulting certificate.
Careful CSR handling reduces the risk of misissuance, service disruption, and cryptographic weakness. Security is strongest when request generation, approval, and storage are treated as part of a controlled process.
8.1 Private key protection
The most important security rule is to keep the private key protected. Since the CSR is signed with that key, any compromise of the private key endangers the certificate workflow and may allow impersonation. Private keys should be stored securely, often with filesystem protections, hardware-backed storage, or dedicated key management systems.
Organizations commonly restrict access to the machine or account that created the key. If a key is suspected to be exposed, the corresponding certificate should be replaced as soon as practical.
8.2 Identity accuracy
The identity fields in a CSR should accurately reflect the entity that will receive the certificate. Incorrect names or alternative entries can lead to failed issuance, deployment errors, or certificates that do not match the intended service. Accuracy is especially important for domain names and other externally visible identifiers.
Because certificate authorities apply policy checks, inaccurate submissions may be rejected or require resubmission. Careful review before submission helps avoid delays and misconfiguration.
8.3 Weak algorithms and key sizes
A CSR should use modern cryptographic algorithms and adequate key sizes or curve parameters. Requests based on weak or outdated methods may be refused by the certificate authority or produce certificates that are unsuitable for current security expectations. The strength of the key pair directly affects the robustness of the certificate.
Using stronger algorithms generally improves longevity and compatibility with contemporary systems. Administrators should choose parameters that align with current best practices and the policies of the issuing authority.