X.509 CSR Summary

Understanding the X.509 Certificate Signing Request

A CSR — Certificate Signing Request — is the file an administrator sends to a Certificate Authority to obtain a TLS/SSL certificate. Technically it is a PKCS#10 structure (RFC 2986) containing the applicant's public key, a Subject Distinguished Name, optional extensions such as Subject Alternative Names, and a self-signature with the matching private key that proves the requester actually holds it. The CA inspects the CSR, validates domain ownership (DV) or organisational identity (OV/EV), strips the parts it does not want to honour and issues an X.509 v3 certificate (RFC 5280) binding the public key to the verified name.

A typical OpenSSL one-liner produces both the key and the CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.key -out example.csr \
  -subj "/C=BR/ST=SP/L=Sao Paulo/O=ACME Inc/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Inspect the result with openssl req -in example.csr -noout -text. The output enumerates the same fields this tool extracts: Subject DN, public key algorithm and length, SAN list, signature algorithm and the request fingerprint.

Subject DN and the death of Common Name

The Subject Distinguished Name is a comma-separated list of RDNs: CN (Common Name), O (Organisation), OU (Organisational Unit), L (Locality), ST (State), C (Country, 2-letter ISO). Historically the CN carried the domain to be secured. Since 2017 (Chrome 58) browsers ignore the CN entirely and rely exclusively on the Subject Alternative Names extension. Issuing a certificate without SAN today is a hard error in every mainstream client — always populate subjectAltName.

Wildcards, SAN lists and the trade-offs

• SAN list — explicit DNS entries: DNS:api.example.com, DNS:app.example.com. Granular and the safest option; CT logs will expose every name.
• Wildcard — *.example.com matches a single label (api, www) but not nested ones (a.b.example.com) nor the apex (example.com itself). Compromise of one host with a wildcard certificate exposes every sibling.
• Multi-domain (UCC/SAN) — a single cert covering unrelated apex domains, useful for Microsoft Exchange and shared hosting; expensive in commercial PKI, free via Let's Encrypt.

Keys, formats and Certificate Transparency

Modern guidance: RSA 2048 minimum (3072 recommended by NIST after 2030); ECDSA P-256 is faster, smaller and equally secure. Files come in two encodings: PEM (Base64 wrapped in -----BEGIN CERTIFICATE REQUEST----- markers, the default for OpenSSL and Linux servers) and DER (raw binary, common on Windows and Java keystores). Convert with openssl req -in csr.pem -outform der -out csr.der. Since Apr 2018 Chrome requires every publicly trusted certificate to appear in at least two Certificate Transparency logs; you can audit your domain at crt.sh or https://transparencyreport.google.com/https/certificates.

FAQ

Do I need root to generate a CSR? No — OpenSSL runs as a regular user. Just protect the private key (chmod 600 example.key) and never commit it to a repository.

Can I reuse an old CSR when renewing? Technically yes, but generating a fresh key pair at renewal is best practice; a leaked key from years ago is harder to detect than to rotate on a schedule. Let's Encrypt and ACME clients do this automatically by default.

What is a self-signed certificate? One where the issuer is the same entity as the subject — useful for development, internal services or as a root for your own private PKI. Browsers will not trust it without manual installation. Generate one with openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365.

Are Let's Encrypt and ZeroSSL really free? Yes. Both are ACME-based and issue Domain Validation certificates at no cost. Let's Encrypt certificates last 90 days and are designed to be renewed automatically by clients such as Certbot, acme.sh or Caddy.