CSR Decoder and Validator Guide: Read a Certificate Signing Request

Getting a certificate starts with asking for one, and the asking is done with a certificate signing request, usually shortened to CSR. A CSR is a structured block of text that says: here is my public key, here is the name and organisation this certificate should be issued for, and here is my signature proving I hold the matching private key. The certificate authority reads the CSR, verifies the signature, and, if everything checks out, issues a certificate binding that public key to that name. The CSR itself is not a certificate, and it grants no trust on its own. It is a request, formatted precisely so that it can be verified mechanically.

The CSR Decoder and Validator tool pastes a certificate signing request in PEM form and checks its basic structure. PEM is the text format you will recognise: a header line reading BEGIN CERTIFICATE REQUEST, followed by lines of base64-encoded data, followed by a footer line reading END CERTIFICATE REQUEST. The tool decodes that block and reports the structure it finds, such as the subject fields and the public key details. Its scope is structural: it checks that the pasted text is a well-formed CSR with readable fields. It does not issue a certificate, it does not confirm that the requester owns the domain named, and it does not verify anything about the certificate authority that will process it. Those are separate steps in the issuance process, and confusing a structural check with an issuance decision is the main misunderstanding to avoid.

The subject of a CSR is a set of named fields, and each one deserves a careful read before the request is sent. The common name field historically carried the domain name, though modern certificates put domain names in a separate subject alternative name extension, and the common name is now often a fallback. The organisation field carries the legal organisation name, the organisational unit carries a department or team if one is used, and the locality, state, and country fields carry the place details. The country field is a two-letter code, such as US or GB, and it must be exactly two letters, not a full country name. The public key section carries the key type and size, such as an RSA key of 2048 bits, and the signature section carries the proof that the requester holds the matching private key. Reading those fields before submission catches the errors that are expensive after issuance, because a certificate issued for the wrong name has to be revoked and reissued, not edited.

The single most important safety rule in this guide is also the simplest: a CSR never contains a private key, and a private key must never be pasted into any checker. The CSR contains the public key, which is designed to be shared, and a signature made with the private key, which proves possession without revealing it. If a paste includes a block reading BEGIN PRIVATE KEY, stop immediately. That key should be treated as exposed, because anything pasted into a web page should be treated as potentially retained, and the correct response is to generate a new key pair and a new CSR, not to hope the paste was harmless. This rule applies to every checker, not just this one, and it is worth repeating to anyone who handles CSRs, because the mistake is easy to make under time pressure and costly to undo.

A worked example you can follow

Take a sample CSR whose subject reads: country GB, state London, locality London, organisation Example Ltd, common name www.example.com. Count the subject fields present: 5. Count the fields you expected: the same 5, so 5 out of 5, or 100 percent, present, with no surprises. Check each one: the country code GB is 2 letters, which passes the length rule, since 2 is exactly the required length. The common name www.example.com matches the domain the certificate is intended for. The organisation Example Ltd matches the legal name on record. So far, the subject passes.

Now read the key section of the same sample. It reports an RSA public key of 2048 bits. Convert that to bytes: 2048 divided by 8 is 256 bytes, which is the size of the RSA modulus. A 2048-bit RSA key is the widely accepted minimum for new certificates, so this sample meets the bar. If the sample had reported 1024 bits, the arithmetic would be 1024 divided by 8, or 128 bytes, and the conclusion would be different: 1024-bit RSA is below the modern minimum, and the CSR should be regenerated with a larger key rather than submitted. The check is therefore not just structural but practical: the key must be both well-formed and strong enough for current expectations.

Take a second, broken sample. Its subject contains 4 fields, but the country field reads United Kingdom instead of GB. The country value has 14 characters including the space, while the required length is 2, so 14 minus 2 is 12 characters too many, and the field fails. The fix is to replace the value with GB and regenerate the CSR, because a CSR's signature covers its contents, and editing the text after generation would invalidate the signature. That is an important general rule: a CSR is signed, so any correction means generating a new CSR, not editing the old text. A third sample is missing its footer line, END CERTIFICATE REQUEST, so the PEM block is incomplete: 1 header present, 0 footers, and the decoder cannot trust the block's boundary. The fix is to re-copy the complete block, header and footer included, and re-check.

Mistakes to avoid

The first mistake is pasting a private key along with the CSR, which exposes the key and forces a full regeneration. The second mistake is editing CSR text by hand after generation, which invalidates the signature and produces a request the authority will reject. The third mistake is submitting a CSR without reading its subject fields, and receiving a certificate for the wrong name, organisation, or country code. The fourth mistake is treating a structural pass as an issuance guarantee. A well-formed CSR can still be rejected for domain control, organisation validation, or policy reasons that no structural check can see, so the structural check is a gate, not a verdict.

The SSL Certificate Checker tool checks the certificate that results from an approved CSR, and the Security DNS Checker tool helps when a certificate problem turns out to be part of a wider site review. For background on how certificates fit into a handover check, see The Pre-Handover Check: Headers, TLS, and DNS in One Routine.

Checking the result before you send the request

Treat a clean structural check as permission to proceed to submission, not as proof the certificate will be issued. Before sending, read the subject fields one final time against the organisation's legal details, confirm the key size meets the current minimum, confirm no private key material is in the paste, and keep a copy of the CSR and the date it was sent. If the authority asks a question about the request, that copy is the reference that answers it without regenerating anything. A CSR that is well-formed, correctly named, strongly keyed, and free of private material is a request ready to be judged on its merits.