CSRs, private keys and certificates: what to send and what to keep
You create a CSR, receive a certificate later, and end up with several similar-looking files. Which certificate belongs to which key? The public key provides the connection between them and helps explain both their roles and how to check a pairing.
The three files have different jobs
A key pair has private material to protect and a public key that can be shared. A CSR requests a certificate for a public key and other supplied information. A CA performs its required checks and issues a certificate for the information it accepts. Creating a CSR does not itself issue a certificate or establish domain control.
What each file contains
RFC 2986 §3–4 defines requests and the issuance flow. A CSR can still contain organization details or internal names, so the absence of private key material is not permission to publish it indiscriminately.
| Item | Main contents | Handling |
|---|---|---|
| Private key | Secret key material used for operations such as signing | Keep it in your controlled environment; a normal certificate request does not send it to the CA |
| CSR, or PKCS #10 request | Public key, subject, attributes and a signature made with the requesting key | Send it to the issuing authority; it does not contain the private key itself |
| Certificate | Public key, names, validity, issuer and related information | Present it to peers; it does not contain the private key itself |
A valid CSR signature is not approval of its claims
The corresponding private key signs the request information. Successful verification establishes that the information was signed with a key consistent with the public key in the request. It does not establish that the stated organization is real or that the requester controls www.example.com.
Compare requested names with the issued certificate
These are illustrative decoded fields. The two SAN names are requests, not a promise that the CA will issue both. Read SAN again in the resulting certificate. Current TLS name verification does not rely on Common Name alone, so entering a CN in a form is not proof that every needed SAN was included.
Subject: CN=www.example.com
Requested SAN: DNS:www.example.com, DNS:example.com
Public key: RSA, 2048 bits
Read and verify a CSR locally
In a controlled environment with OpenSSL, this command displays a CSR and verifies its request signature. Replace request.csr with the CSR filename. No private key is needed for this operation.
Example CSR input
Read Subject, Public Key and SAN under Requested Extensions. Signature success concerns internal consistency of the request; it does not certify domain ownership, CA approval or a valid TLS certificate. See the official OpenSSL req options.
openssl req -in request.csr -noout -verify -text
Extract public keys to check the pairing
Matching domain names in filenames do not prevent an old key from being paired with a new certificate. Use the same OpenSSL installation to extract each public key in PEM form, then compare the outputs. Choose output filenames that do not overwrite existing files.
Extraction without displaying the private key
Matching PUBLIC KEY blocks show the same public key in that representation. Enter an encrypted-key password interactively rather than putting it on the command line. Also check that each command succeeded and produced nonempty output. Public-key agreement does not establish certificate validity, trust or the absence of private-key exposure.
openssl pkey -in private-key.pem -pubout -out key-public.pem
openssl req -in request.csr -pubkey -noout -out csr-public.pem
openssl x509 -in certificate.pem -pubkey -noout -out cert-public.pem
Use test keys for the online workflow
The Online Tools CSR tool generates the key and CSR on the server, and sends entered CSRs there for parsing. For a test, enter www.example.com as CN and www.example.com,example.com as SAN, then inspect the returned names. Generate and keep production private keys in an environment you control and trust.
What the key matcher compares
The key and certificate matcher sends the certificate, private key and password to its server, so use test pairings. For RSA and EC, it compares the public key derived from the private key with the public key in the certificate. Agreement does not establish certificate validity. Its chain display compares Issuer and Subject ordering; it does not verify signatures or establish trust.
Specifications and checks after issuance
RFC 2986 §4: request structure; RFC 5958 §2: private-key information; OpenSSL pkey; OpenSSL x509. Continue with TLS chains, SAN and trust for connection failures, or the PEM, DER, P7B and PFX guide for file preparation.