Certificate & PKI

An X.509 certificate is a structured document containing a public key, the identity it's issued to (the subject), the identity that issued it (the issuer), a validity period, and a digital signature from the issuer over the whole certificate. Certificates are typically distributed in PEM format — base64-encoded DER data wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers — which is why decoding a certificate's actual fields, rather than just eyeballing the encoded block, requires a dedicated parser.

Trust is established through a chain: a leaf (end-entity) certificate is signed by an intermediate CA certificate, which is itself signed by a root CA certificate. Browsers and operating systems ship with a curated set of trusted root certificates; a chain validates successfully only if it can be followed, link by link, from the leaf up to one of those pre-trusted roots, with every signature in between verifying correctly and no certificate in the chain expired or revoked.

Getting a certificate issued starts with a Certificate Signing Request (CSR): a document containing your public key and the identity you're requesting a certificate for, signed with the corresponding private key to prove you actually hold it. A CA reviews the CSR (the depth of review depends on the certificate validation level requested), and if approved, issues a signed certificate back — the CSR itself is never the certificate; it's the request that leads to one.

Beyond the certificate itself, a live TLS connection also negotiates a cipher suite — the specific combination of key exchange, authentication, encryption, and integrity algorithms both sides agree to use for that session. A perfectly valid certificate chain doesn't guarantee a secure connection if the negotiated cipher suite itself is weak or deprecated.

A typical certificate lifecycle starts with generating a key pair and a matching CSR. Use the CSR Generator to build a properly-formatted request with the correct subject fields for your domain, then the CSR Decoder to verify it contains exactly the fields you intended before submitting it to a certificate authority.

Once a certificate is issued, use the PEM Certificate Decoder or the X509 Certificate Inspector to confirm its subject, issuer, validity dates, and extensions match what you requested — catching a misconfigured field here is far cheaper than discovering it after deployment. Use the SSL Certificate Chain Validator to confirm the full chain, from your leaf certificate through any intermediates to a trusted root, validates correctly and in the right order.

For an already-deployed service, use the TLS Cipher Suite Explorer to audit which cipher suites a server actually negotiates and flag any that are outdated or weak, and the SSL Expiration Checker to monitor how much runway remains before a certificate needs renewal — the single most common, most avoidable cause of a sudden production TLS outage is a certificate nobody was tracking quietly expiring.

To audit whether a certificate was issued for your domain without your knowledge — a real attack vector when a CA is compromised or tricked — use the Certificate Transparency Lookup to search the public CT logs every publicly-trusted CA is required to publish to, and confirm every certificate listed for your domain is one you actually requested.

Mistake: deploying a leaf certificate without its required intermediate certificate(s). Many browsers cache intermediates from prior visits and won't show an error, while a fresh client or a strict validator will fail the chain — always deploy the full chain (leaf plus intermediates), not just the leaf certificate alone.

Mistake: letting a certificate's expiration date go unmonitored until it actually expires. Because a valid certificate produces no warning signs before its expiry, this is one of the few TLS failures that's entirely predictable in advance and entirely avoidable with routine monitoring, yet remains one of the most common causes of unplanned outages.

Troubleshooting: if a browser reports a chain validation failure despite the certificate itself looking correct, check the intermediate certificates first — a missing, wrong-order, or expired intermediate is a far more common cause than a problem with the leaf certificate itself.

Troubleshooting: if a CSR is rejected by a CA, decode it first to confirm the subject fields (especially the exact domain name and any Subject Alternative Names) match precisely what you intended — a mismatched or malformed field in the original CSR is a more common rejection cause than a CA-side issue.

The X.509 certificate format itself is defined by ITU-T X.509 and profiled for internet use by RFC 5280, which specifies the certificate and CRL (Certificate Revocation List) structure actually used in TLS.

Certificate Signing Requests follow the PKCS #10 format, defined by RFC 2986. The broader PKCS key and certificate format family (including PKCS #1 for RSA keys) is defined by RFC 8017 and related documents.

Certificate Transparency, the public-logging system this hub's CT lookup tool queries, is defined by RFC 6962 (and its successor RFC 9162), created specifically to make undetected mis-issuance of certificates structurally harder.

JSON Web Key (JWK), the key-format this hub's JWK tools generate and convert, is defined by RFC 7517 — distinct from RFC 7519 (JWT) and RFC 7515 (JWS), which the Authentication & Tokens Lab hub covers for token construction and signing.

Certificate validation level (Domain Validation, Organization Validation, Extended Validation) trades issuance speed and cost against the depth of identity verification a CA performs — DV is sufficient for most services where proving domain control is the actual security requirement; OV and EV add organizational identity checks that matter more for certain compliance or user-trust contexts than for the cryptographic security of the connection itself, which is identical across all three levels.

For the underlying key type a certificate's public key uses, the same RSA-versus-ECC tradeoff applies here as anywhere else asymmetric cryptography is used — see the RSA vs ECC comparison in the Encryption hub for the detailed breakdown; most modern deployments default to ECC for its smaller key size and faster handshakes unless a specific compatibility requirement calls for RSA.

When auditing a server's negotiated cipher suites, prioritize removing suites that use deprecated algorithms (RC4, 3DES, or SHA-1-based MACs) or that don't provide forward secrecy, over chasing marginal performance differences between two already-modern suites — the security gap between a modern and a deprecated cipher suite is far larger than the practical difference between two reasonable modern choices.

The same cryptographic key can be represented in several different text or binary formats depending on what system needs to read it: PEM (base64-encoded, with descriptive header/footer markers) is the most common for TLS certificates and keys; JWK (a JSON object with named fields for the key's components) is the format web-oriented token systems expect; and SSH has its own distinct public-key line format, unrelated to either.

Use the Public Key Extractor to pull just the public key out of a certificate or a private key file when you need to share only the non-sensitive half, and the Private Key Inspector to verify a private key's algorithm, size, and passphrase-protection status without ever transmitting the key itself anywhere.

Use the JWK Generator to produce a new key directly in JWK format, or the JWK ↔ PEM Converter when a key exists in one format but the system you're integrating with expects the other — a common friction point when a certificate-issued key needs to be used by a JWT-signing library that only accepts JWK input.

SSH keys follow their own format, distinct from X.509 entirely — no certificate authority or chain of trust is involved by default; instead, trust is established the first time you connect to a new host (see the Hashing & Integrity hub's coverage of SSH key fingerprinting for that verification step). Use the SSH Key Generator to create a new key pair and the SSH Public Key Decoder to inspect an existing public key's algorithm, size, and any embedded comment field.