What is CSR (Certificate Signing Request)?

What a CSR contains

A CSR holds three things:

• The subject: the name and details that are to appear in the certificate.
• The public key that is to be certified.
• A signature made with the matching private key.

Why a CSR is signed

The signature proves possession. It shows that whoever made the request holds the private key for the public key inside it. Without that check, someone could ask for a certificate on another person’s public key. The CSR does not prove who the requester is. The authority does that separately, for example by checking a citizenship certificate.

How a CSR is made and used

In outline:

• Generate a key pair on a device or token. The private key stays there.
• Build the request with the subject details and sign it.
• Send the CSR, with identity evidence, to the authority.
• The authority validates, issues an X.509 certificate and returns it.
• Install the certificate next to the private key.

Is it safe to share a CSR

Yes. A CSR contains no secret. Anyone who sees it learns the public key and the name, nothing more. The private key must never be sent, emailed or pasted into a form, whatever the request says. In the ePahichan app the key is created in the phone’s secure hardware and the request is built for you, so there is no file to handle.

CSR and certificate renewal

Renewing a certificate usually means sending a new CSR. Some authorities let you keep the same key pair and others require a fresh one. A fresh pair is the better habit, because an old key may have been exposed without anyone noticing. After renewal, the old certificate keeps working until its end date unless it is revoked.

If a CSR has a mistake, such as a misspelt name, the authority cannot fix it for you. The request has to be made again, because the subject is covered by the signature on the request. Check the details before sending, and compare them with the certificate you receive back, since the authority may adjust names to match the documents you supplied.

What the authority checks in a CSR

The authority first checks that the signature on the request verifies, which proves the sender holds the private key. It then compares the subject details with the identity evidence you supplied. A name that differs from your citizenship certificate, even in spelling, is a common reason for a request to be returned.

Next it checks the key itself. Keys that are too short or made by a weak generator are refused. Only then is the certificate built, with the authority’s own choices for the validity period and key usage, which are not taken from the request. This is why you may find the certificate differs from what you asked for in details the authority controls.

Example: from request to certificate

A person installs the app. The phone creates a key pair in its secure hardware, builds a CSR containing the public key and the person’s name, and signs the CSR with the private key. The request goes to the authority with a photo of the citizenship certificate and a live selfie. The authority checks these, signs a certificate, and sends it back. The app stores it.

The person never saw the CSR. That is the point of a good app: the technical steps are handled, but they still happen in this order, and the private key stays where it was made.