# CSR decoder > Decode a PKCS#10 certificate signing request to read its subject, public key, requested SANs and extensions, and attributes — entirely in your browser. - Tool: https://ronutz.com/en/tools/csr-decoder - Family: Certificates & PKI --- ## What it does Decode a PKCS#10 certificate signing request and read what it contains: the subject name, the public key, the Subject Alternative Names and other extensions the requester is asking for, and any attributes. It parses the request's structure entirely in your browser and never contacts a certificate authority. ## What a CSR is, and what it is not A CSR is the object you hand to a certificate authority when you ask it to issue a certificate. The important thing is that it is not a certificate. It has no serial number, no issuer, and no validity dates, because none of those have been decided yet. It carries only what the requester is asking for: a subject name, a public key, and optionally a set of requested extensions such as Subject Alternative Names. The whole request is signed with the private key that matches the public key inside it, which proves the requester actually holds that private key, a step called proof of possession. ## Requested, not granted Reading a CSR tells you what was asked for, not what a CA will grant. A certificate authority is free to add, change, or drop what a CSR requests according to its own policy and the validation it performs, so the SANs and extensions you see here are a request, not a guarantee. This distinction matters when an issued certificate does not match the CSR: that is often the CA applying policy, not an error. ## What it decodes The request is DER-encoded ASN.1 (the same tag-length-value encoding certificates use), and the decoder walks it into readable fields: - the **subject** distinguished name; - the **public key** and its algorithm and size; - the **requested extensions**, carried in a PKCS#9 `extensionRequest` attribute, most importantly the Subject Alternative Names; and - other **attributes** such as a challenge password or an unstructured name, where present. It decodes structure only. It does not verify the request's self-signature, and because a CSR has no validity window, there is nothing time-relative to check. ## Using it Paste a PKCS#10 CSR (the block between the CERTIFICATE REQUEST markers) and read its subject, key, requested SANs and extensions, and attributes. The parse is deterministic and local. ## Standards and references - [RFC 2986 — PKCS #10: Certification Request Syntax Specification v1.7](https://www.rfc-editor.org/rfc/rfc2986) - CertificationRequest / CertificationRequestInfo structure - [RFC 2985 — PKCS #9: Selected Object Classes and Attribute Types](https://www.rfc-editor.org/rfc/rfc2985) - extensionRequest, challengePassword, unstructuredName attributes - [RFC 5280 — Internet X.509 PKI Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280) - Name, SubjectPublicKeyInfo, Extensions encodings reused by CSRs - [ITU-T X.690 — ASN.1 encoding rules (BER/CER/DER)](https://www.itu.int/rec/T-REC-X.690) - DER tag-length-value encoding the decoder parses ## Related reading - [ACME on BIG-IP: from DevCentral scripts to a native client](https://ronutz.com/en/learn/bigip-acme-certificate-automation.md): How Let's Encrypt and other ACME certificate automation works on F5 BIG-IP: the native ACMEv2 client introduced in BIG-IP 21.1.0 (provisioning, renewal, and deployment for any ACMEv2 CA), the community dehydrated-based solutions that came before it, BIG-IQ's centralized Let's Encrypt CA management profile, and where the shared ACME concepts and rate limits fit. - [ACME on FortiGate: a built-in client for the box's own certificate](https://ronutz.com/en/learn/fortigate-acme-certificate-automation.md): How FortiOS's native ACME support obtains and renews a Let's Encrypt certificate for the FortiGate itself: the public-IP and FQDN requirements, the single-name SAN constraint, the TLS-ALPN-01 and HTTP-01 challenges (and which FortiOS versions support them), the GUI and CLI configuration, and how this differs from BIG-IP's native client. - [ACME: how certificates issue and renew themselves](https://ronutz.com/en/learn/acme-protocol.md): How the ACME protocol automates certificate issuance end to end: the account, the order, the three challenge types, the dns-01 record you publish, and the finalize-and-download step that produces the certificate. - [Anatomy of an X.509 Certificate](https://ronutz.com/en/learn/x509-anatomy.md): What lives inside a TLS certificate, how the ASN.1/DER bytes are structured, what the v3 extensions actually control, and why decoding a certificate is not the same as trusting it. - [Certificate signing requests and how certificates are issued](https://ronutz.com/en/learn/certificate-signing-request.md): What a CSR contains, why your private key never leaves your machine, how a CA validates and issues, and how ACME automates the whole exchange. - [How certificate validation actually works](https://ronutz.com/en/learn/certificate-validation.md): The steps a client runs to decide a certificate is trustworthy: building the chain, checking signatures and dates, matching the name, and enforcing constraints. - [PEM, DER, and the certificate file formats](https://ronutz.com/en/learn/certificate-formats.md): Why the same certificate comes in so many file shapes, what PEM and DER actually are, and what .crt, .pem, .pfx, and .p12 really hold. - [Public vs private PKI: which certificates SC-081v3 governs](https://ronutz.com/en/learn/public-vs-private-pki.md): The 47-day schedule binds publicly trusted TLS certificates only. What separates public from private PKI, why internal CAs are exempt, and how to read the planner's compliance verdict for an internal certificate.