An SSL/TLS certificate is a digital document (X.509 standard) that cryptographically binds a public key to an identity to enable encrypted HTTPS sessions.
An SSL/TLS Certificate (formally structured under the ITU-T X.509 standard and RFC 5280) is a digitally signed electronic credential that establishes trust between a client (such as a web browser or API consumer) and a server. It cryptographically binds an asymmetric public key to a specific identity—such as a Fully Qualified Domain Name (FQDN), IP address, or legal organization.
When a client initiates an HTTPS connection, the server presents its X.509 certificate. The client verifies the certificate's cryptographic signature against a pre-installed repository of trusted root Certificate Authorities (CAs). Once verified, the client and server negotiate symmetric session keys using the public key to establish a private, encrypted TLS tunnel.
Decode raw PEM blocks offline or inspect live certificate chains and expiration timelines using our free client-side SSL/TLS Certificate Decoder or analyze server headers with our HTTP Headers Analyzer.
| Specification | Technical Details |
|---|---|
| Standard Specifications | ITU-T X.509 v3, IETF RFC 5280, RFC 6818 |
| Common File Extensions | .pem, .crt, .cer, .der, .p7b, .pfx, .p12 |
| Default Text Format | PEM (ASCII Armor Base64 wrapped around ASN.1 DER binary) |
| Max Industry Validity | 398 days (~13 months, mandated by CA/Browser Forum) |
| Primary Public Key Types | RSA (2048-bit, 4096-bit), ECDSA (NIST P-256, P-384), Ed25519 |
| Mandatory Subject Identifiers | Subject Alternative Names (SANs) per RFC 6125 / RFC 2818 |
Every standard X.509 version 3 certificate consists of three primary sections: TBSCertificate (To-Be-Signed Certificate), SignatureAlgorithm, and SignatureValue.
Certificate (ASN.1 Sequence)
├── TBSCertificate (Payload signed by Issuer)
│ ├── Version (v3 = 0x02)
│ ├── Serial Number (Unique integer per CA)
│ ├── Signature Algorithm Identifier (e.g., ecdsa-with-SHA256, sha256WithRSAEncryption)
│ ├── Issuer Distinguished Name (C, O, CN of CA)
│ ├── Validity Period (notBefore, notAfter in UTC/GeneralizedTime)
│ ├── Subject Distinguished Name (Identity requested)
│ ├── SubjectPublicKeyInfo (Algorithm OID + Public Key bits)
│ └── Extensions (v3 only)
│ ├── Subject Alternative Names (SANs: DNS names, IP addresses)
│ ├── Basic Constraints (isCA: true/false, pathLenConstraint)
│ ├── Key Usage (Digital Signature, Key Encipherment, etc.)
│ ├── Extended Key Usage (Server Authentication, Client Auth)
│ ├── Subject & Authority Key Identifiers (SKI / AKI hashes)
│ ├── Authority Information Access (AIA: OCSP & CA Issuers URLs)
│ └── CRL Distribution Points (Download URIs for CRLs)
├── SignatureAlgorithm (Matches TBS signature identifier)
└── SignatureValue (Cryptographic signature generated by Issuer CA private key)
Public SSL/TLS security depends on a hierarchical trust model called the Chain of Trust:
example.com). It does not have certificate signing permissions (isCA: false).isCA: true.[Root CA (Pre-installed in OS / Browser Trust Store)]
│
▼ (signs)
[Intermediate CA (Must be bundled on web server)]
│
▼ (signs)
[Leaf / End-Entity Certificate (Assigned to your domain)]
[!WARNING] If a web server serves only the leaf certificate without the intermediate CA certificate (e.g.,
cert.peminstead offullchain.pem), mobile devices, cURL, and backend API clients will reject the connection withSSL_ERROR_UNTRUSTED_ISSUERbecause they cannot build the trust path to the root.
Historically, domain identities were placed in the Common Name (CN) attribute of the Subject Distinguished Name.
*.example.com) appear explicitly inside the Subject Alternative Name (SAN) extension (id-ce-subjectAltName, OID 2.5.29.17).| Metric | RSA (2048 / 4096-bit) | ECDSA (P-256 / P-384) |
|---|---|---|
| Mathematical Basis | Prime Factorization | Elliptic Curve Discrete Logarithm |
| Key Size for 128-bit Security | 2048-bit (or 3072-bit) | 256-bit (NIST P-256) |
| TLS Handshake Size | Larger (~1.5–2.5 KB) | Much Smaller (~0.5–1.0 KB) |
| CPU Signature Verification | Fast | Very Fast |
| CPU Signing & Handshake Speed | Moderate | Extremely Fast |
| Legacy Client Compatibility | 99.9% (Ancient systems) | 99.5% (All modern browsers/OSes) |
When notAfter timestamp passes, modern web browsers immediately block access to the website with prominent security warning screens (ERR_CERT_DATE_INVALID or SEC_ERROR_EXPIRED_CERTIFICATE). API calls via cURL, Axios, or fetch will throw fatal network exceptions.
Yes. In a self-signed certificate, the Subject and Issuer are identical, and the certificate is signed by its own private key. While suitable for local development or internal testing, public web browsers will reject self-signed certificates with severe warnings because the signing key is not rooted in the browser's trusted CA repository.
A wildcard certificate secures all single-level subdomains under a domain (e.g., api.example.com, app.example.com, blog.example.com). However, per RFC 6125, wildcards do not cover the apex domain (example.com) without a separate SAN entry, nor do they cover nested sub-subdomains (such as dev.api.example.com).
Certification Authority Authorization (CAA) is a DNS resource record (RFC 6844) allowing domain owners to designate which specific Certificate Authorities (e.g., Let's Encrypt, DigiCert) are authorized to issue certificates for their domain, mitigating rogue issuance risks.
Free, browser-based utilities to test, generate, and inspect SSL/TLS Certificate & X.509 Standard payloads directly.
Decode PEM & X.509 certificates offline or inspect live SSL/TLS certificate chains with expiration countdowns and health checks.
Analyze HTTP response headers for security, caching, and compliance issues.
Look up DNS records for any domain — A, AAAA, MX, TXT, NS, SOA, SRV, CAA, and more.
Build and validate Content Security Policy headers with security scoring.