Network Security
Certificate Signing Request
A certificate signing request is a formatted message a requester sends to a certificate authority to apply for a digital certificate, containing the requester's public key and identifying information, signed with the corresponding private key to prove key ownership.
In plain terms
A certificate signing request is the application form you send to get a digital certificate. It includes your public key and who you are, signed with your private key to prove the key is really yours. The certificate authority checks it and, if satisfied, issues your certificate.
A certificate signing request, commonly abbreviated CSR, is the message an applicant submits to a certificate authority when requesting a digital certificate. It packages the information the authority needs to issue a certificate: the applicant’s public key and identifying details such as the domain name or organization the certificate will represent. The CSR is signed with the applicant’s own private key, which proves to the authority that the applicant actually possesses the private key corresponding to the public key being submitted. The CSR is therefore the formal first step in obtaining a certificate within a public key infrastructure.
The process begins with the applicant generating a key pair, a private key and a public key. The private key is kept secret and never leaves the applicant’s control, while the public key is included in the CSR. Along with the public key, the CSR carries identity information, often expressed as a distinguished name including elements like the common name, which is typically the domain for a TLS certificate, and organizational details. The applicant signs the CSR with the private key, and this self-signature lets the authority verify that whoever submitted the request holds the private key matching the enclosed public key, an important check called proof of possession.
Once the certificate authority receives the CSR, it performs its validation and issuance process. The authority verifies the request, which for different certificate types involves different levels of identity checking, ranging from simply confirming control of a domain to thoroughly vetting an organization’s identity. If the authority is satisfied, it issues a certificate by taking the public key and identity from the CSR and signing them with the authority’s own private key. The resulting certificate binds the applicant’s identity to their public key and carries the authority’s signature, which is what allows relying parties to trust it. Importantly, the applicant’s private key is never sent to the authority; only the public key in the CSR is, which is why the private key can remain secret.
The CSR illustrates the separation between what is public and what is private in certificate issuance. Because only the public key and identity travel to the authority, the security of the private key is preserved throughout the process. This is fundamental: a certificate vouches for a public key, and the matching private key must stay solely with its owner for the certificate to be meaningful. If the private key were exposed during the request, the trust the certificate represents would be undermined. The CSR is designed so that the private key is used only to sign the request locally, proving possession without disclosure.
CSRs are part of routine certificate management, which has grown in importance as certificates have become ubiquitous and their lifetimes shorter. Organizations generate CSRs whenever they need a new certificate or renew an existing one, and managing this at scale, generating keys securely, producing CSRs, submitting them, and installing the issued certificates, is a significant operational task. Automation has become common, with protocols that handle certificate issuance and renewal programmatically, often generating CSRs and obtaining certificates without manual steps. This automation reduces errors such as expired certificates while still relying on the underlying CSR mechanism.
From a security standpoint, the handling of the key pair around a CSR matters as much as the request itself. The private key should be generated with good randomness and stored securely, and access to it controlled, because the certificate that results is only as trustworthy as the protection of the corresponding private key. Mistakes such as generating weak keys, exposing private keys, or reusing keys inappropriately undermine the value of the certificate regardless of the CSR being correctly formed. The CSR is the entry point to a certificate’s life, and sound key practices at that point set the foundation for the certificate’s trustworthiness.
In practice, a certificate signing request is the standardized application that begins the issuance of a digital certificate, conveying the requester’s public key and identity to a certificate authority and proving possession of the private key without revealing it. The authority validates the request and signs a certificate binding the identity to the public key, completing the link that makes the certificate trustworthy. Understanding the CSR clarifies how certificates are requested and issued within a PKI, and why the careful separation and protection of the private key throughout the process is essential to the trust a certificate ultimately conveys.