What does a CSR check do?
A CSR check runs a fixed set of tests against a certificate signing request and reports a pass, a warning or a failure for each. It verifies the request's signature against the public key inside it — the one test that is arithmetic rather than policy — then weighs the key algorithm and size, the signature hash, whether subject alternative names are present, whether those names are shaped like host names, and whether the common name is within the length limit the baseline rules impose. The whole set is available as a copyable report.
Checking first is worth the few seconds because a certificate authority takes minutes to hours to answer, and a rejection typically names one problem at a time, so a request with two defects takes two round trips. The four things that account for most refusals are all decidable from the file: a signature that will not verify, a key below the minimum size, a hash no longer accepted, and a name left out of the alternative names while the common name was filled in instead.
What the tool cannot decide is stated plainly. Whether a name is yours to request depends on the proof of control you supply, which is the authority's job to check; whether the request will be accepted depends on the authority's own rules. So a clean report means nothing in the file would stop it being issued, not that it will be. Read it that way and it is a useful filter; read it as approval and it will disappoint you.
How to check a CSR before sending it
- Paste the request text, or open a .csr or .pem file.
- Press Check this request; six checks run in order of how decisive they are.
- If the signature check fails, stop there — the bytes have been altered or the key does not match, and nothing else matters until that is fixed.
- Look at the key and hash lines, which follow published baselines and are definite refusals when they fail.
- Read the names checks: a warning about missing alternative names is the most common avoidable mistake.
- Copy the report into a ticket or a message to whoever generated the request.
Check CSR limits and rules
| Item | Limit |
|---|---|
| Input | PEM text, bare Base64, or a raw DER file; up to 4 MB |
| Signature | Verified against the request's own public key, using the browser's cryptography |
| Key checks | Algorithm identified and size weighed against the 2048-bit RSA and 256-bit curve minima |
| Hash check | SHA-1 and MD5 signatures are reported as failures, since authorities refuse them |
| Name checks | Presence of alternative names, duplicates, and whether each is shaped like a host name |
| Common name | Checked against the 64-character limit in the baseline requirements |
| Not covered | Domain ownership, authority policy, and whether the request will be issued |
When to use it
- Catching a missing subject alternative name before it costs a round trip with the authority.
- Confirming that a request really was signed by the key it carries after copying it between machines.
- Checking that a script generating requests is producing keys of the right size.
- Producing a short report to attach to a support ticket about a rejection.
- Auditing a batch of requests one at a time while migrating a fleet of certificates.
Is it private?
The request is read and verified in this page. Nothing is uploaded, stored or logged. Only the public half of the key is in a request, so there is nothing secret to protect — but there is also no reason for it to leave the browser.
Frequently asked questions
Because that is what a signature is for. The request was signed with the private key, and the matching public key travels inside the file. Verification uses the public key to check the signature over the request body — no secret is needed, and none is present. This is precisely why the test is decisive: it proves that whoever created the request held the private key, and that the body has not been altered since, using nothing but what the file already contains.
It means the browser's cryptography refuses the algorithm, not that the request is bad. The common case is a request signed with MD5, which no browser will touch, and the occasional one is an unusual parameter combination in RSASSA-PSS. In both situations the request is almost certainly going to be refused by an authority anyway, so treat it as a problem worth fixing rather than an inconclusive result — regenerate the request with SHA-256 or better.
Because it is not always fatal. A public authority will not issue a certificate on a common name alone, but it can supply the alternative names itself from whatever proof of control you provide — so a request with no names can still be issued, it just will not be issued for the names you thought you were asking for. Treating it as a warning rather than a failure is the honest reading: the request is not invalid, it is incomplete in a way you should decide about deliberately.
It tests the structure of each requested name and nothing else: that it has at least one dot, that its labels start and end with a letter or digit, that they contain only letters, digits and hyphens, and that it is not longer than 253 characters. A leading wildcard label is allowed. It does not test whether the name resolves, who owns it, or whether the authority will accept it — those are questions about the world, not about the string.
No — the two have different structures and this tool will report that it does not look like a request. A certificate's signature is made by the issuer, whose key is in a separate file, so the self-signed check that works for a certificate cannot apply to a request's signature either way round. Use the Certificate Decoder to read a certificate, and this tool to audit a request before it becomes one.
They follow the long-standing baselines that public authorities have enforced for years: RSA of at least 2048 bits, elliptic curves of at least 256 bits, and SHA-256 or better for the signature. These have not moved recently, and there is no sign of RSA 2048 being retired on a short timescale — but thresholds do drift over years, and an authority's own documentation is always the final word. The checks here match what will be accepted today.
Related tools
Written and maintained by Md. Nur Hossain Repon.