Free tool
What is my certificate request actually asking for?
A signing request is twenty lines of base64 that you fill in once a year and never read back. Paste it here and you get the name it carries, the key size, the names it asks to cover, and the structural flaws that get a request turned down.
Whatever you paste is decoded by your own browser. It is never sent to a server, not even ours: not the certificate, not the request, not the domain name.
What this tool reads, and what it does not
It reads the structure — the subject, the public key, the requested extensions — and runs the same structural checks a CA runs. It does not verify the signature on the request, and it has no way of knowing whether the matching private key is still on your server. Both of those take one command line, and the command table below has them.
You make a request once, the expiration date comes back every year
The certificate you are about to receive carries an end date. It is the most predictable outage in this line of work and still one of the most common, because nobody goes back to read the date on a certificate installed eleven months ago. DomainVigil reads yours every day and writes before the deadline, not after. This decoder helps on the day you make the request; the date is the part that comes back.
How it works
The counter: what gets a request turned down
A signing request goes off to the CA, and the answer comes back an hour later: refused, with nothing more. Here are the four fields behind almost every refusal. Get one of them wrong and watch the stamp.
Certificate signing request — example.com
Nothing to report: this request clears the counter. Break a field to see what the CA would have answered.
Nothing is sent anywhere — this counter is a drawing. To examine your own request, paste it in the field at the top of the page.
What a request contains
The private key is not in it.
A request carries the public key and a signature. The signature is what proves you hold the private key, without ever handing it over.
- 1key, and it is the public one
- 0dates: a request never expires
- 9fields it can carry
Reading the result
The banner gives the main name and the overall verdict. Below it, each panel is one piece of the request, in the order it is encoded.
- Fine
- The request clears the structural checks: a common name that is repeated in the name list, a key of at least 2048 bits, a SHA-256 signature. Your CA may add rules of its own, but nothing here will get the request rejected on reading.
- Problem
- A flaw that gets the request rejected: a key too short, an obsolete digest, a common name missing from the name list, a malformed name. You redo the request, and sometimes the key with it — a short key cannot be stretched.
- Worth checking
- A request that will be signed, but may not cover what you think it covers: a wildcard without the bare domain, an email address in the subject, a duplicate. Nothing here blocks, and all of it is fixed by redoing the request from the same key.
- Good to know
- A detail that judges nothing: a challenge password, an unusual attribute. It is flagged because it often explains why two requests that look identical come back as different certificates.
- Names covered
- Each chip is one entry in the subject alternative name list, with its type. Those names, and only those, are what the signed certificate will authenticate. The common name is not one of them unless you repeated it there.
- Requested extensions
- A request does not contain extensions, it contains a request for them, carried by the extensionRequest attribute. The CA copies them over, completes them or ignores them according to its policy. Each one is shown with its identifier, so you can line the list up against what comes back in the certificate.
The five rejections that come back the most
These are the ones that show up when you order a certificate for a client, with the cause and the fix for each.
The CA answers “the common name is not in the SAN”
What causes it: The request was generated with a CN field and nothing else, no alternative name list. A certificate carrying only the CN identifies nothing to a browser, and CAs will not sign one.
What fixes it: Regenerate the request from the same key, adding the extension: openssl req -new -key key.pem -out request.csr -addext "subjectAltName=DNS:example.com, DNS:www.example.com". Repeat the common name inside the list.
The certificate comes back and refuses to install
What causes it: The request was generated on one server and the certificate installed on another, or the key was regenerated in between. A certificate seals the public key from the request, and it works with that private key and no other.
What fixes it: Line up the three modulus fingerprints with the commands in the table below. If the certificate's differs from the key's, the key behind the request is not the one on the server — redo the request and ask for a reissue.
The certificate is fine, and the bare domain throws a name error
What causes it: The request carried *.example.com and nothing else. A wildcard covers names one level down, never the name it sits on.
What fixes it: Ask for both: *.example.com and example.com. That is the only way to cover the subdomains and the bare domain at once.
The request is turned down over an accented name
What causes it: The dNSName field of a certificate carries ASCII and nothing else, so an accented name has to appear there in its encoded form, the one that starts with xn--.
What fixes it: Convert the name and put the ASCII form in the request. The Punycode converter in this family of tools goes both ways.
The private key went missing between the request and the delivery
What causes it: The request was generated in a hosting panel, in a container that has been rebuilt since, or in a temp folder. Without the private key, a signed certificate is worth nothing.
What fixes it: Make a new key and a new request, then ask the CA for a reissue — usually free, and usually with no revalidation. And keep the key wherever the certificate lives, from day one.
The fields of a request, and what each one commits you to
A request carries more fields than make it into the certificate. Here is what becomes of each one, and the identifier it is encoded under.
| Field | What it holds | What it commits to |
|---|---|---|
| CN — 2.5.4.3 | One name, 64 characters at most (RFC 5280, appendix A). | It no longer identifies the site — RFC 2818 § 3.1 requires the alternative names to be used whenever they exist. Repeat the main name in there, or it goes uncovered. |
| subjectAltName — 2.5.29.17 | The list of names, carried by the extensionRequest attribute. | This is the list that counts. A name missing from it is not covered, even when it appears in the common name. |
| O — 2.5.4.10 | The organization's legal name. | Verified for an organization-validated certificate, stripped out of one validated on the domain alone. |
| OU — 2.5.4.11 | A department, a team, a site. | No effect at all. Public authorities stopped carrying this field over. |
| C, ST, L — 2.5.4.6, .8, .7 | The country, the state or region, the city. | The country expects a two-letter code. A spelled-out country name gets the request rejected on reading. |
| emailAddress — 1.2.840.113549.1.9.1 | An email address in the subject. | Comes from PKCS#9 and has no business in a website certificate. Leave it empty. |
| subjectPublicKeyInfo | The algorithm and the public key. | RSA at 2048 bits or more, or a P-256 curve. This is the key the certificate will seal, and there is no changing it afterward. |
| challengePassword — 1.2.840.113549.1.9.7 | A password defined by PKCS#9 § 5.4.1. | Public authorities ignore it. Leave it empty. |
| signatureAlgorithm | The algorithm that signs the request itself. | SHA-256 at the very least. This signature is what proves that whoever is asking for the certificate holds the private key. |
The identifiers are each field's OID. That is the form the tool falls back to for a field it does not recognize, rather than inventing a name for it.
The commands that go with it
Every one of them was run while writing this page, on OpenSSL 3.6. They work just as well with the LibreSSL that ships with macOS.
| Command | What it does |
|---|---|
| openssl req -new -newkey rsa:2048 -nodes -keyout key.pem -out request.csr | Creates a 2048-bit private key and the request that goes with it, with no passphrase on the key. |
| openssl req -in request.csr -noout -text | Prints the contents of the request to the terminal, field by field. |
| openssl req -in request.csr -noout -verify | Verifies the signature on the request. Answers “self-signature verify OK” when the request and the key belong together. |
| openssl req -in request.csr -noout -modulus | openssl sha256 | The fingerprint of the public key modulus, on the request side. |
| openssl rsa -in key.pem -noout -modulus | openssl sha256 | The same fingerprint, on the private key side. |
| openssl x509 -in certificate.crt -noout -modulus | openssl sha256 | The same again, on the certificate you got back. All three have to match, or the certificate will not install. |
| openssl req -new -key key.pem -out request.csr -addext "subjectAltName=DNS:example.com, DNS:www.example.com" | Redoes a request from a key you already have, with the alternative name list. |
Frequently asked questions
What is a CSR actually for?
To tell a certificate authority which name you want certified and with which public key. The request holds the public key, never the private one; it is signed with the private key, which proves you hold that key without handing it over. The CA checks that the domain is yours, then returns a certificate sealing that public key and those names.
Can I decode a CSR without uploading it somewhere?
Yes, two ways. On the command line: openssl req -in request.csr -noout -text. Or here: the decoding is written in JavaScript and runs in your own browser, so what you put in the field never reaches a server. A certificate request is not a secret, but sooner or later somebody pastes one file too many.
Why repeat the name in the SAN when it is already in the CN?
Because the common name no longer identifies the site. RFC 2818 § 3.1 says that when a subjectAltName extension of type dNSName is present, that extension is the identity, and the common name is read only when it is absent. CAs stopped issuing certificates without it, and a name that is not in the list is covered by nothing.
Do I have to generate a new private key at every renewal?
Nothing requires it: you can build a new request from the key you already have, with openssl req -new -key key.pem. Rotating the key limits how long a compromised one stays useful, at the cost of a slightly heavier deployment. Both practices are in use; what matters is knowing where the key is stored.
Can one request cover several names?
Yes, through the subjectAltName extension, and that is the normal way to do it: a certificate routinely covers the bare domain, the www subdomain and a few others. The common name field takes one and only one. A *.example.com wildcard counts as one name and covers a single level of subdomains.
Does a CSR expire?
No. A request carries no date at all, so it never goes stale. The certificate carries two, a start and an end, and this tool shows them in days for a certificate that has already been issued. A request you sat on for six months is still technically usable, but nothing obliges a CA to sign it.
From request to certificate
Four steps, and one single key throughout
You fill in a request once a year and never read it back. Here is what becomes of each of its parts, and that is where half the rejections come from.
You generate a key, then the request
The private key stays with you. The request carries the public key, the common name and the list of names to cover, and it is signed with the private key.The CA reads the paperwork before it checks the domain
A common name of 64 characters at most, repeated in the name list, a key of at least 2048 bits, a SHA-256 signature. One flaw here and the request comes back without anyone ever looking at the domain.It returns a certificate that seals that key and those names
The certificate is good for the public key in the request and no other. The O, OU, C, ST and L fields are kept, completed or dropped according to CA policy; the name list is the part that counts.You install it with the original private key
If the key is gone, or was regenerated in the meantime, the certificate will not install. At that point you make a new request and ask for a reissue.
The limits
Three values an authority does not negotiate
All three are read in the request itself, before any domain check. This is where the dumbest rejections happen.
2048bits
The minimum size of an RSA key
Under that, the request is turned down. A key that is too short cannot be stretched — you generate a new one and redo the request from it.
64
The characters allowed in the common name
The field limit, set in appendix A of RFC 5280. Past it, the request is rejected on reading, before anyone looks at the domain.
3
The modulus fingerprints that have to match
One from the request, one from the private key, one from the certificate you get back. If any of them differs, the certificate will not install — and the command table gives the three lines that compute them.
The 2048-bit minimum is the one this page applies and the one public authorities require; the 64-character limit on the common name comes from appendix A of RFC 5280; the three fingerprints are the ones in the command table above.
Twenty checks, no sign-up
- What is inside this certificate?
- What does this domain name look like in Punycode?
- Has my DNS change propagated yet?
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?