Verifying & Troubleshooting CSR Errors

Verification Is Not One Thing — It's Three

"Is this CSR okay?" actually bundles together three independent checks that fail for completely different reasons, and conflating them is the single biggest source of confused troubleshooting. First, structural validity: does the file parse as a well-formed PKCS#10 ASN.1 structure at all. Second, signature validity: does the embedded signature cryptographically check out against the embedded public key. Third, policy acceptance: does a specific CA's own rules — domain ownership, organization vetting, key type policy — accept what's being requested. A CSR can pass any combination of these three independently of the others: a file can parse perfectly and still carry an invalid signature if a single byte got corrupted in transit; a signature can verify cleanly on a CSR requesting a domain the submitter doesn't control; and a structurally and cryptographically perfect CSR can still bounce off a CA that simply doesn't accept the key type used. Keeping these three checks mentally separate is what makes the rest of this guide's troubleshooting steps make sense.

Verifying the Signature: openssl req -verify Explained

The command openssl req -in file.csr -noout -verify performs exactly the second check above: it extracts the public key from the CSR's own SubjectPublicKeyInfo field, then uses that same key to check whether the signature at the end of the CSR is a valid signature over the CertificationRequestInfo bytes. A successful check prints verify OK; a failure prints Signature verification failure. It's worth being precise about what this does and doesn't prove: it proves the person or system that produced this file possessed the private key matching the embedded public key at the moment of signing, and that the signed content hasn't been altered since. It does not prove the requester actually controls the domain named in the request, and it does not check the request against any CA's issuance policy — those are separate steps a CA performs independently after receiving a structurally valid, signature-verified CSR.

Confirming a CSR Matches a Specific Private Key

A subtly different question from signature verification is whether a given CSR file corresponds to a specific private key file you have sitting next to it — relevant when you've regenerated a CSR at some point and aren't sure which key file goes with which request. The reliable technique is comparing public keys directly: openssl req -in file.csr -noout -pubkey extracts the public key the CSR embeds, and openssl pkey -in file.key -pubout derives the public key from the private key file; if both commands' output is byte-identical, they're a matched pair. For RSA specifically, an equivalent shortcut compares just the modulus: openssl req -noout -modulus -in file.csr against openssl rsa -noout -modulus -in file.key, which is faster to eyeball since it's a single hex value rather than a full PEM block. This check matters because a certificate issued against a CSR is only usable together with that CSR's original private key — pairing a certificate with the wrong key file results in a server that fails to start TLS at all, with an error pointing at a key/certificate mismatch.

Reading OpenSSL's Actual Error Messages

Malformed PEM: The Non-Cryptographic Failure Mode

A large share of "broken CSR" reports have nothing to do with cryptography at all — they're plain-text formatting problems in how the PEM block itself is stored or transmitted. The PEM format requires an exact -----BEGIN CERTIFICATE REQUEST----- opening line and matching -----END CERTIFICATE REQUEST----- closing line, with the Base64-encoded content between them conventionally wrapped at 64 characters per line (though most parsers tolerate different wrapping). Common corruption sources: a text editor that auto-converts line endings between Unix LF and Windows CRLF inconsistently partway through a file; a chat or email client that collapses multiple consecutive line breaks into one; a copy-paste that drags in invisible trailing whitespace on each line; or a web form that HTML-escapes characters that shouldn't be escaped. The fix is almost always the same regardless of the specific corruption: regenerate the CSR fresh and transfer it via a method that preserves plain text exactly (a downloaded .csr file rather than a copy-pasted terminal selection, for instance), rather than trying to manually repair a corrupted PEM block byte by byte.

CA Rejection vs Structural Invalidity: Two Different Problems

It's worth restating the distinction from the opening section in concrete terms, because the fix for each is completely different. A structurally invalid CSR (fails to parse, fails signature verification) needs to be regenerated — there's no policy discussion to be had with a CA about a file their systems can't even read. A CA rejection of a structurally valid CSR, by contrast, is a business/policy decision responding to something about the request's content: an unverified domain, an organization name that doesn't match business registry records, or a key type outside the CA's accepted range. Reading a rejection notice carefully to determine which category it falls into saves significant back-and-forth — "malformed request" errors mean regenerate the file; "domain validation pending" or "organization vetting required" errors mean the CSR itself is fine and the delay is elsewhere in the CA's process.

SAN Mismatches: The Most Common Real Rejection

By a wide margin, the most frequent real-world CSR-content rejection is a SAN list that doesn't cover every hostname the resulting certificate needs to serve. This typically happens one of two ways: the CSR was generated before a decision was made to also cover a www or other subdomain variant, and nobody regenerated it afterward; or a wildcard was intended (*.example.com) but only the bare apex domain was actually included in SAN, leaving every subdomain uncovered. The practical fix is always the same — regenerate the CSR with a complete, deliberately-reviewed SAN list before resubmitting, since a CA can only issue a certificate covering exactly what was requested; there's no mechanism to add a name to an already-issued certificate without a fresh CSR and reissuance.

Domain Validation Failures Traced Back to the CSR

Domain Validation (DV) failures are frequently misdiagnosed as a CSR problem when the CSR itself is entirely fine. A CA's domain validation checks — a DNS TXT record, an HTTP file placed at a specific path, or an email sent to a role address at the domain — verify control of the exact hostnames listed in the CSR's SAN field, independent of anything else in the request. If validation fails, the fix is almost never to change the CSR; it's to correctly complete whichever validation method the CA specified, for the exact hostname spelling the CSR requested (a validation attempt for example.com doesn't satisfy a CSR requesting www.example.com, since they're different names requiring independent proof of control).

Key Type and Size Policy Rejections

CA policies on acceptable key types and minimum sizes vary more than most people expect, and this is a rejection category that's entirely avoidable by checking policy before generating a CSR rather than after submission. RSA below 2048-bit is rejected essentially everywhere as an industry-wide baseline. RSA 2048 and 4096 are near-universally accepted. ECDSA acceptance is where real variance shows up: some CAs, particularly enterprise and government PKI systems built around older tooling, don't support ECDSA CSRs at all and require RSA regardless of your own preference. Checking a specific target CA's documented key policy — a five-minute check — before generating a CSR avoids the wasted cycle of generating, submitting, waiting for rejection, and regenerating with a different key type.

A Systematic CSR Troubleshooting Checklist

When something's wrong and the cause isn't immediately obvious, working through checks in this order avoids chasing the wrong problem: First, confirm the file parses at all with openssl req -in file.csr -noout -text — if this fails, the issue is PEM formatting or file corruption, not content. Second, run openssl req -in file.csr -noout -verify — if this fails on a file that parsed fine, suspect corruption introduced after signing or a tampered file. Third, if both pass, review the decoded Subject and SAN fields against exactly what you intended to request — most remaining issues at this point are content mismatches, not technical failures. Fourth, if the CSR still gets rejected by a CA despite passing all of the above, the rejection reason is a policy matter (domain validation, organization vetting, key policy) and the CSR itself doesn't need to change — the underlying issue does.

Real Troubleshooting Scenarios

A developer copy-pastes a CSR from a terminal session into a CA's web form and gets a base64 decode error — the terminal's line-wrapping silently altered the text; downloading the CSR as a file instead resolves it immediately. A sysadmin inherits a certificate renewal task and finds two similarly-named .key files in a directory, unsure which matches the CSR already submitted — comparing modulus values with openssl req -noout -modulus against each candidate key settles it in seconds rather than guessing. A team requests a certificate covering both app.example.com and api.example.com but only lists one in SAN, discovers the gap only after the second subdomain throws browser warnings post-issuance, and has to generate a fresh CSR with both names and go through reissuance. A CSR generated years ago with a 1024-bit RSA key gets flatly rejected by a CA that's since raised its minimum, requiring nothing more than a fresh CSR at 2048-bit against the same subject details.

Related Reading

For a structural walkthrough of what's actually encoded inside a CSR before you get to verifying it, see our companion guide Decoding a CSR: Reading SAN & Subject Fields. To generate a fresh, correctly-formed CSR from scratch, use the CSR Generator. To inspect an existing CSR's decoded fields without the command line, use the CSR Decoder. For what happens after a certificate is issued and needs checking, see Fix an Expired SSL Certificate and the SSL Certificate Checker.