PKI: CSR, certificates, and SANs (overview)

PKI (public-key infrastructure) is the set of practices and formats that bind an identity to a public key so browsers, APIs, and mutual-TLS clients can trust “this server is api.example.com” or “this client is device X.” You do not need a full CA hierarchy to understand the pieces developers touch every day: a keypair, a certificate signing request (CSR), an X.509 certificate, and Subject Alternative Names (SANs).

This overview explains what each artifact is for, why SANs matter more than the old Common Name habit, when self-signed certs are enough, and how to generate or inspect them locally without uploading private keys.

The three artifacts (and what they are not)

Artifact	What it contains	Who signs it	Typical use
Keypair	Public + private key (RSA, ECDSA, …)	Nobody—keys are generated	Prove possession; decrypt or sign
CSR (PKCS#10)	Public key + requested identity (DN, SANs)	You sign with your private key	Ask a CA (or your own tooling) to issue a cert
Certificate (X.509)	Public key + identity + validity + extensions	A CA (or yourself, if self-signed)	What TLS and most APIs actually trust

A certificate is not a private key. Sharing a .crt or leaf PEM is normal; sharing the matching private PEM is a compromise. PEM is only the text wrapper—see What is in a PEM file? and RSA keypairs: sizes and PEM.

Distinguished Name (subject) fields

The subject is a set of name attributes (a Distinguished Name). Common fields:

Attribute	Short	Example
Common Name	CN	api.example.com or a human-readable label
Organization	O	Acme Corp
Organizational Unit	OU	Platform
Country	C	US (two-letter)
State / Province	ST	California
Locality	L	San Francisco

Historically, browsers matched hostnames against CN. Modern TLS clients expect hostnames in the SAN extension instead. Many CAs still require a CN for formality, but DNS names you care about belong in SANs. Treat CN as a display/legacy field, not the source of truth for HTTPS host matching.

What a CSR actually requests

A CSR packages:

1. The public key you want certified
2. The subject DN you are asking for
3. Optional extensions such as DNS SANs
4. A signature proving you hold the corresponding private key

You send the CSR (and never the private key) to a public CA, an internal CA, or ACME automation. The CA validates domain control (or your org policy), then returns a signed certificate. The private key never needs to leave the machine that generated it—ideal for browser-local or HSM workflows.

LocalTools’ PKI Certificate Studio builds PKCS#10 CSRs from a keypair you generate in the same tab (RSA or ECDSA; Ed25519 keys can be generated/exported, while CSR/self-signed issuance in the studio uses RSA or ECDSA).

Subject Alternative Names (SANs)

SANs list the identities the certificate is valid for. For HTTPS, that almost always means DNS names (and sometimes IP addresses):

DNS:api.example.com
DNS:www.example.com
DNS:*.staging.example.com

Why SANs matter	Detail
Hostname matching	Clients check the URL host against SAN DNS (or IP) entries, not CN alone
Multi-host certs	One cert can cover apex + www + API hosts without separate leafs
Wildcards	*.example.com covers one label under example.com, not nested levels like a.b.example.com
Mismatches	“NET::ERR_CERT_COMMON_NAME_INVALID” and friends are usually SAN problems, despite the old error name

When you fill “DNS Subject Alternative Names” in a local builder, put one host per line (or comma-separated). Empty SANs may still produce a CSR or self-signed cert with only a CN—fine for some internal experiments, brittle for real browser HTTPS.

Self-signed vs CA-signed

Kind	Issuer	Browsers / OS trust	Good for
Self-signed	Same key signs the cert	Not trusted by default	Local HTTPS, staging, mTLS lab setups you pin yourself
CA-signed	Public or private CA	Trusted if the CA is in the trust store	Production public websites, most corporate TLS

A self-signed certificate still has a subject, SANs, not-before / not-after, and a public key. It is cryptographically valid; it is simply not in the world’s default trust anchors. For production public sites you submit a CSR to a CA. For localhost and internal services, self-signed (or a private CA) is often enough if clients are configured to trust it.

Inspecting what you already have

Before renewing or filing a ticket, read the leaf:

• Subject and issuer (self-signed ⇒ subject ≈ issuer)
• Not before / not after (clock skew and expiry)
• SANs (does the host you hit appear?)
• Serial (revocation / inventory)

Paste a PEM cert or chain into a local inspector; typically the first certificate block is the leaf. Private keys should stay out of shared pastes—prefer PEM Decoder for label/DER checks and PKI Studio’s Inspect tab for subject, issuer, validity, and SANs. Nothing needs to leave the device; see Why “local only” matters for developer tools.

Common pitfalls

• Hostname only in CN — modern clients expect SANs; add every DNS name you will serve.
• Wrong private key with the cert — TLS fails if the leaf’s public key does not match the key your server loads.
• Expired or not-yet-valid — check not-before/after in the client’s timezone/clock.
• Uploading private PEM to “online CSR generators” — generate keys and CSRs locally or in your CA’s approved tooling.
• Assuming self-signed “doesn’t need SANs” — browsers still match SANs for HTTPS even when you click through trust warnings.
• Wildcard misunderstanding — *.example.com does not cover example.com itself; list both if needed.

Try it in the browser

Use PKI Certificate Studio to:

1. Key Gen — create RSA 2048/4096 or ECDSA P-256/P-384 (or export Ed25519 PEM for external tooling).
2. CSR / Cert — set CN and optional O/OU/C/ST/L, add DNS SANs, then generate a PKCS#10 CSR or a self-signed certificate for dev/staging.
3. Inspect — paste or drop a .pem / .crt and confirm subject, issuer, validity, and SANs—then clear private material from the tab.

Related reading: RSA keypairs: sizes and PEM for modulus choices, What is in a PEM file? for BEGIN CERTIFICATE / CERTIFICATE REQUEST labels, and Why “local only” matters for developer tools for the privacy model.