What is a CSR (Certificate Signing Request)?
Short answer
A CSR (Certificate Signing Request) is the request prepared to obtain a certificate from a CA: it contains the public key and the identity information to be written into the certificate (CN, SAN, organization name) and is signed with the private key. The private key stays on the side that generates the request; only the CSR goes to the CA, and the CA returns the certificate it has signed. In TR7, a CSR is created on the SSL/TLS Certificates screen, in the CSR (External CA) tab; the key is generated on the device or selected from the Private Key Library and is not sent to the CA, and when the certificate signed by the CA is uploaded to the same request, a certificate record that can be assigned to a vService is created.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| Certificates & PKI → SSL/TLS Certificates → CSR (External CA) → Add | Request Name, Common Name (CN), Subject Alternative Names, Private Key (Generate a new key for this request, Use a key from the library), Key Algorithm | Generating the CSR and the key |
| CSR (External CA) list → right-click | Download the CSR, Upload the signed certificate, Re-issue: upload a newly signed certificate | Giving the CSR to the CA; uploading the signed certificate; having the same CSR signed again and updating the same record |
| CSR (External CA) list | Status: Waiting for signature, Signed | Whether the request has been signed |
| Certificates & PKI → Certificate Authorities (CA) | Enroll under an external CA → Upload the signed CA certificate | Having the CSR of the issuing CA set up in TR7 signed by the organization's CA |
How Does It Work?
- The requester generates a key pair; the private key stays with the requester.
- The public key and the identity information are collected in a CSR, which is signed with the private key (RFC 2986, PKCS #10).
- The CA verifies the signature in the CSR and the requester's authority over the domain, and signs the certificate.
- The signed certificate is uploaded back to the side that generated the request and is matched with the private key.
Common Misconceptions
- "A CSR also carries the private key." A CSR carries only the public key; in TR7, the private key is not sent to the CA and stays on the device where it was generated.
- "Every renewal requires a new CSR." In TR7, the signed request is kept; if the same CSR is given to the CA again and the certificate is uploaded with Re-issue, the key and the vService assignments do not change (Can I create a CSR on TR7?).
- "The CA uses every field in the CSR as it is." As its policy requires, the CA can change or ignore some fields (e.g. O, OU); the SAN list is limited to the names the CA approves.
How it is done in the documentation
