X.509
The standard format for public-key certificates. Every TLS certificate, every PKI artifact you've ever encountered, is X.509.
X.509 is the ITU-T standard that defines the format of public-key certificates. The format used by SSL, TLS, S/MIME, code signing, and basically every other PKI on the internet. When you look at a TLS cert, you're looking at an X.509 certificate.
The current version is X.509v3 (RFC 5280), in widespread use since 1999.
What's in an X.509 cert
Roughly:
- Version (almost always 3).
- Serial number (unique within the issuing CA).
- Signature algorithm (SHA256-RSA, ECDSA-P256, etc.).
- Issuer (the CA's distinguished name).
- Validity period (Not Before / Not After dates).
- Subject (the entity the cert is issued to).
- Subject public key.
- Extensions (Subject Alternative Names, Key Usage, CRL Distribution Points, OCSP URLs, etc.).
- Signature from the CA.
It's all in ASN.1 (a complicated binary encoding) and usually serialized in PEM (base64-encoded with -----BEGIN CERTIFICATE----- markers) or DER (raw binary).
When the format matters
- Parsing certs in code. Use a real X.509 library (Go's
crypto/x509, Python'scryptography, Node's built-in TLS). Don't try to parse the bytes yourself. - Reading a cert.
openssl x509 -in cert.pem -text -nooutdumps the fields in human-readable form. - Generating a CSR.
openssl reqgenerates a Certificate Signing Request, which is an X.509-formatted request sent to a CA.
What "X.509" usually means in conversation
Nine times out of ten, someone says "X.509 cert" when they mean "TLS cert" or "code signing cert." There's almost no scenario where the format matters more than the use case. The exception is interop debugging: when one tool parses a cert and another rejects it, the issue is almost always non-standard X.509 extensions or signature algorithms.