CSR Viewer

Paste a CSR — a PKCS#10 certificate signing request — or load a .csr / .pem file, and read what it actually asks a certificate authority to sign. The viewer base64-decodes the PEM to DER, parses the ASN.1, and pulls out a plain summary: the subject distinguished name, the public key algorithm and size, any requested subject alternative names, and the signature algorithm. A full tag/length/value tree sits below the summary for the details. Everything runs in your browser, so the request and its key stay on your machine.

How to use the CSR Viewer

Paste a certificate request into the box, or load a .csr or .pem file. Leave Input on auto-detect for a normal PEM block; switch it to base64 or hex if you only have the raw DER body without the -----BEGIN CERTIFICATE REQUEST----- wrapper. The viewer decodes the request and shows a summary card first: the subject distinguished name field by field, the public key algorithm with its RSA modulus size or EC curve, the subject alternative names requested through the extension-request attribute, and the algorithm the request is self-signed with.

Below the summary is the complete ASN.1 tree, the same structure a tool like openssl req -text walks, so you can confirm exactly what the CA will see. Object identifiers are resolved to names, so a signature reads sha256WithRSAEncryption rather than a dotted number and subject fields read commonName and organizationName. The parse runs entirely client-side with no network calls, which makes it safe to inspect a request and the public key inside it before you send it off. The CSR also carries a signature made with the matching private key, but the private key itself is never part of a CSR and is not needed here.

What a CSR is and what it contains

A certificate signing request is the message you send to a certificate authority to ask it to issue a certificate. Its format is defined by PKCS#10, and like the certificate it leads to, it is an ASN.1 structure encoded in DER and usually wrapped in a PEM block labelled CERTIFICATE REQUEST. A CSR has three parts. The certification request info holds the data you are asking to have certified: a version number, the subject distinguished name, the subject public key info (your public key plus its algorithm), and a set of attributes. That info is then signed, and the request carries the signature algorithm and the signature itself.

The signature is the clever part. You sign the request with the private key that matches the public key inside it, which proves to the CA that you actually hold the private key for the key you are asking it to certify — a proof of possession. The CA verifies that self-signature, checks the identity claims against its own validation rules, and only then issues a certificate. Crucially, the private key never appears in the CSR; only the public half does. That is why a CSR is safe to share and why this viewer needs nothing secret to decode one.

The most practically important and most often misunderstood part is the attributes, specifically the extensionRequest attribute. Modern certificates are validated against their subject alternative name entries, not the legacy common name, so the hostnames you actually want covered have to be requested as SAN entries inside this attribute. A request that names a host only in the subject common name, with no SAN, will often produce a certificate that browsers reject. Being able to see the requested SANs, the key type and size, and the signature algorithm at a glance is exactly what catches these mistakes before a request goes to a CA and burns an issuance. It is also how you confirm a request generated by an unfamiliar tool or appliance contains what you intended rather than a surprise default.

Common use cases

  • Checking a request before submission. Confirm the subject, key size and requested SANs are right before sending a CSR to a CA.
  • Debugging a rejected certificate. Find the missing or wrong subject alternative names that made a certificate fail validation.
  • Auditing a key. Read the public key algorithm and RSA modulus size or EC curve a request was generated with.
  • Inspecting an appliance request. See what a router, load balancer or device actually put in a CSR it generated.
  • Private review. Decode an internal request locally without uploading it to an online CSR decoder.

Frequently asked questions

Does a CSR contain my private key?
No. A PKCS#10 request contains only your public key, the subject and requested attributes, and a signature made with the matching private key to prove you hold it. The private key never appears in a CSR, so a CSR is safe to share and nothing secret is needed to decode one.

Why does the summary highlight subject alternative names?
Because modern certificate validation uses SAN entries, not the legacy common name. SANs are requested through the extensionRequest attribute inside the CSR. A request that lists a hostname only in the subject and omits the SAN often yields a certificate browsers reject, so seeing the requested SANs is the quickest way to catch that mistake.

What input formats are accepted?
A PEM block beginning with -----BEGIN CERTIFICATE REQUEST-----, or the raw DER body as base64 or hex if you do not have the wrapper. You can also load a .csr, .pem or .der file. Auto-detect chooses the format, or you can set it explicitly.

How is this different from the PEM and ASN.1 viewers?
The PEM and ASN.1 viewers show the generic structure of any block. This viewer knows the PKCS#10 layout, so on top of the full tree it extracts a labelled summary — subject, public key, requested SANs and signature algorithm — which is what you usually want from a CSR.

Is the request uploaded anywhere?
No. The CSR is base64-decoded and its ASN.1 parsed entirely in your browser with no network calls. The request and the public key inside it never leave your device, so it is safe for internal or private material.