What is a CSR?

Certificate Signing Request (CSR) is a file that a client or device generates, containing its public key and identifying information such as the common name and subject alternative names, and submits to a certificate authority. The CA verifies the request and returns a signed digital certificate the requester can install.

Key takeaways

• A CSR carries a device’s public key and identity fields, never its private key.
• The device signs the CSR with its private key to prove it holds the pair.
• The CA verifies the request and returns a signed digital certificate.
• CSRs can be generated manually or automated through SCEP, CMP, or ACME.
• Versa Director, Concerto, and VMS all generate and submit CSRs to a CA.

On this page: Why it matters · How it works · Types · CSR & Versa · FAQ

Why is a CSR important?

A CSR is the starting point of nearly every trust relationship built on public key infrastructure (PKI). Before two systems can authenticate each other over TLS, mutual TLS, or IPsec with certificate-based authentication, one side needs a certificate that a trusted certificate authority has signed – and a CSR is how that process begins. Generating the CSR on the requesting device, rather than having the CA generate the key pair, means the private key never leaves the device that will use it, keeping the sensitive half of the key pair out of transit entirely.

CSRs also matter operationally, because certificate issuance has to scale to thousands of devices, servers, and services without becoming a manual bottleneck. Automated enrollment protocols build directly on the CSR format so a device can request, renew, and replace certificates on a schedule instead of waiting on a manual export-and-import cycle. Getting the identity fields right – common name, subject alternative names, validity period – also determines whether TLS clients will actually trust the resulting certificate, since modern validation checks the SAN list, not just the common name.

What is a CSR?

A CSR is a PKCS#10-formatted file built in three steps. First, the requesting client or device generates a public/private key pair locally. Second, it assembles the request body: the public key, a distinguished name that identifies the requester (country, state, locality, organization, organizational unit, and – most critically – a common name), plus usually one or more subject alternative names covering every hostname or IP address the certificate must be valid for. Third, the device signs the whole request with its own private key, which proves to the CA that the requester actually holds the private key matching the public key in the request, without ever sending that private key anywhere.

The signed CSR is then submitted to a certificate authority – directly, through a manual process, or automatically, through an enrollment protocol such as SCEP, CMP, or ACME. The CA validates the requester’s identity against its own policy, then issues a signed certificate binding the public key to the requested identity. The requester installs that certificate alongside the private key it already holds, and the CSR itself is discarded.

Types of CSR

How a CSR gets generated and submitted varies by deployment. Manual/CLI generation uses a command-line tool – OpenSSL, or a vendor script such as VMS’s vsh generate-server-csr – to build the key pair and CSR interactively, with an administrator entering the identity fields and copying the resulting file to a CA for signing. Orchestrator-driven generation happens through a management UI: an administrator fills in CSR fields (common name, email, country, validity, key size) in a workflow, and the platform generates and submits the request as part of onboarding a device or tenant. Protocol-automated enrollment removes the manual step entirely – SCEP, CMP, or ACME clients generate the CSR, submit it to a CA server automatically, and handle renewal before the certificate expires, the model most large fleets use to avoid certificate-expiry outages.

A CSR can also target a self-signed authority – useful for labs and internal testing – or a CA-signed (third-party) authority for anything that must be broadly trusted. The fields inside the CSR stay the same either way; only the trust root differs.

CSR & Versa

Versa uses CSRs in two layers of the platform. On Versa Messaging Service, the vsh generate-server-csr command builds a CSR on the primary node, prompting for five to seven subject alternative names covering the management, elastic, and southbound interfaces, plus organization and common name – the resulting server-csr.pem goes to a trusted CA for signing, then comes back through vsh import-ca-certs. HA VMS deployments instead generate a self-signed root CA and CSR chain locally with the vms_cert_gen.sh script, producing root, server, and client certificates for the cluster.

On the Secure SD-WAN side, tenant configuration in Concerto drives CSR generation entirely through workflow fields – an administrator selects a CA server type (ACME, CMP, or SCEP), then fills in CSR options such as common name, shared key, validity, and private key size per controller. Concerto converts those entries into CSR bind data that appliances submit automatically when published, so certificate-based tenant authentication doesn’t require touching a device shell at all.

Frequently asked questions

What information does a CSR contain?

A CSR contains the requester’s public key and a distinguished name: common name, and usually organization, locality, state, country, and one or more subject alternative names. It is signed with the requester’s private key to prove possession, but the private key itself is never included in the file.

Does a CSR include a private key?

No. A CSR includes only the public key half of the key pair; the private key stays on the requesting device and is used only to sign the request, proving the device holds it, without ever transmitting it to the CA or anywhere else.

What is the difference between Common Name and Subject Alternative Name in a CSR?

Common Name is the traditional single identity field, historically a hostname. Subject Alternative Name is a newer extension listing every hostname, IP address, or identity the certificate should cover. Modern TLS clients validate against the SAN list, so most current CSRs populate both fields.

How does a CSR relate to SCEP, CMP, and ACME?

SCEP, CMP, and ACME are enrollment protocols that automate what a manual CSR workflow does by hand: generating the CSR, submitting it to a CA, and retrieving the signed certificate. Versa devices can use any of these server types instead of a manually copied CSR file.

Can a CSR be reused for multiple certificates?

A single CSR is normally submitted once and consumed by the CA that signs it. To request a renewed or reissued certificate – or to change identity fields such as SAN entries – the requester generates a new CSR rather than resubmitting the original.

More on CSR

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about CSR, these are worth looking at next.