What is SSL? Everything you need to know about certificates and encryption
Most "what is SSL" pages are written by salespeople. This one is written by people who have worked with PKI and certificates for over 16 years.
We explain SSL/TLS at three levels: from the basics (what is the padlock?) through the technical mechanics (handshakes, certificate chains, key types) to advanced topics for IT professionals (cipher suites, Certificate Transparency, trust stores, ACME). Jump to the level that suits you.
Level 1: The basics
What is an SSL certificate?
An SSL certificate is a small data file installed on a web server. It solves three fundamental problems:
Identity: Is it really the bank?
When you visit www.your-bank.com, the certificate guarantees that you are actually communicating with the bank's server and not an attacker. An independent certificate authority (CA) has verified the owner's identity and digitally signed the certificate, so your browser can trust it.
Encryption: No one can read along
Your browser and the server establish an encrypted connection between themselves. The certificate does not perform the encryption itself, but ensures during the setup that you are negotiating with the correct server and not an attacker in between.
Once the connection is established, all data is encrypted. No one along the way can read the content. Even your internet service provider can only see which server you are visiting, not what you send or receive.
Data integrity: No one can alter data in transit
If anyone attempts to modify data in transit, the recipient detects it immediately and terminates the connection. This prevents attackers from injecting false information or malicious code into the data stream between you and the server.
SSL vs TLS: What is the difference?
SSL (Secure Sockets Layer) was the original protocol from Netscape. It is deprecated and insecure. All modern connections use its successor, TLS (Transport Layer Security). The industry still uses "SSL" as a catch-all term, but the certificate is the same regardless of TLS version.
Developed by Netscape. So insecure it was never deployed.
First public version. Fundamentally insecure.
Better, but broken by the POODLE attack (2014). Deprecated.
IETF took over development and renamed the protocol. Dropped by browsers in 2020.
Marginal improvements. Dropped by browsers in 2020.
Still widespread. Secure with correct configuration (ECDHE + AEAD only).
Current standard (RFC 8446). Removed all insecure algorithms. Faster handshake. Forward secrecy by default.
HTTP vs HTTPS
HTTP sends data in plaintext. Everyone between you and the server can read along: internet service providers, wifi hotspot owners, every router along the way. HTTPS adds TLS encryption, making data unreadable to everyone except the sender and receiver.
All modern browsers mark HTTP pages as "Not Secure". Google uses HTTPS as a ranking signal, and many web technologies (HTTP/2, Service Workers, Geolocation API) require HTTPS. There is no good reason to run HTTP today.
The three validation types
Certificates come with different levels of identity verification. The validation type determines how thoroughly the CA has vetted you as the certificate owner, not how strong the encryption is (that is the same):
Confirms that you control the domain via DNS or HTTP challenge. Automatic issuance, typically under 2 minutes with ACME. Cheapest. No company details in the certificate.
Also verifies your business registration against public registries. The company name appears in the certificate's Organization field. FairSSL performs OV validation in English for GlobalSign, typically under 1 hour.
Strictest verification with legal, operational and physical confirmation. Shows company name and country in the certificate. Required for code signing certificates and certain industries.
All three types provide the same encryption strength. Browsers no longer show a green bar for EV (Chrome removed it in version 77, September 2019, and other browsers followed). The company details are still in the certificate, but users must click the padlock to see them.
Certificate types: Single Domain, Wildcard and SAN
- Single Domain: Covers one specific domain, e.g.
www.your-domain.com. Most DV certificates automatically include bothwwwand the base domain as a SAN (Subject Alternative Name). - Wildcard: Covers all subdomains at one level under a domain, e.g.
*.your-domain.com(coverswww,mail,apietc.). Does not cover the base domainyour-domain.comitself unless it is added as an extra SAN. Does not cover deeper levels such assub.api.your-domain.com. - Multi-Domain (SAN): Covers a list of specific names, which can be from entirely different domains:
your-domain.com,your-domain.co.uk,your-shop.com. The number of allowed SANs varies by product (typically 25-250).
The choice depends on your infrastructure. Wildcard is easier to manage, but all servers share the same private key. If one server is compromised, the key can be used to impersonate any subdomain. SAN certificates give more control and can mix domains freely. See our wildcard SSL page and multi-domain SSL page for a detailed comparison.
Level 2: How it works technically
TLS handshake: What happens when you open an HTTPS page?
When your browser connects to an HTTPS server, a TLS handshake is performed. In TLS 1.3 it takes one round trip (typically 50-100 ms). The purpose is to agree on an encryption key without ever sending the key over the network:
- 1 Client Hello. The browser sends a list of supported TLS versions, cipher suites and key exchange parameters (key shares). In TLS 1.3 the browser already sends its key share in the first message, so the server can respond immediately.
- 2 Server Hello + certificate. The server selects a cipher suite and sends its key share. It then sends its certificate (with the public key and the entire certificate chain) in an encrypted message, protected by the just-agreed key.
- 3 Certificate verification. The browser checks: is the certificate issued by a trusted CA? Has it not expired? Does the domain name match (in the SAN field)? Is it logged in Certificate Transparency? Has it been revoked? Does the chain build correctly up to a trusted root?
- 4 Session keys. Already in steps 1-2 the browser and server exchanged key shares via Elliptic Curve Diffie-Hellman (ECDHE). These are combined into a shared secret used to derive session keys. The private key is never sent over the network. Even if someone captures the entire handshake, they cannot compute the session key.
- 5 Encrypted communication. All subsequent traffic is encrypted with the session key (symmetric encryption, typically AES-256-GCM or ChaCha20-Poly1305). Symmetric encryption is orders of magnitude faster than asymmetric.
TLS 1.3 vs 1.2: TLS 1.2 uses two round trips (double the latency). It also allows RSA key exchange (no forward secrecy), CBC-mode ciphers (vulnerable to padding oracle attacks) and a wide range of insecure configurations. TLS 1.3 removed all of that. If your server still offers TLS 1.0 or 1.1, they should be disabled. All modern browsers have dropped support for them.
What is inside a certificate? (X.509 anatomy)
An SSL certificate is an X.509v3 certificate encoded in ASN.1 DER format (typically Base64-encapsulated as PEM). It contains:
SAN (Subject Alternative Name) is the field that actually determines which domain names the certificate covers. CN (Common Name) in the Subject field is used historically, but modern browsers ignore CN and use SAN exclusively. A certificate without SAN will be rejected.
The certificate chain: Root, intermediate and leaf
Your SSL certificate (the leaf certificate) is part of a chain of trust. The browser verifies the chain from your certificate up to a trusted root:
Root certificates are pre-installed in trust stores maintained by four major root programmes: Microsoft (Windows/Edge), Apple (macOS/iOS/Safari), Mozilla (Firefox) and Google (Chrome Root Store, launched 2023). To be included, the CA must pass a WebTrust or ETSI audit and comply with CA/Browser Forum Baseline Requirements.
Your server must send the full chain (leaf + intermediate), but not the root certificate (the browser already has it). The order matters: leaf first, then intermediates in ascending order.
Common mistake: If the server only sends the leaf certificate without the intermediate, browsers on some platforms cannot verify the chain. Desktop Chrome can often find the missing intermediate itself (via Authority Information Access), but mobile browsers and curl/Python fail. Always verify the chain with our SSL Scanner.
Cross-signing in practice: When a CA has a new root that is not yet in all trust stores, it can cross-sign its intermediate with an older, broadly trusted root. Let's Encrypt used this: their ISRG Root X1 was cross-signed by IdenTrust DST Root CA X3 to achieve compatibility with older devices. When DST Root CA X3 expired on 30 September 2021, it broke certificate verification on older Android devices, OpenSSL 1.0.x and many IoT devices worldwide.
Key types: RSA vs ECDSA
The certificate's key type determines which cryptographic algorithm is used to sign and verify the certificate. There are two common types:
| Property | RSA | ECDSA (P-384) |
|---|---|---|
| Key size | 2048 or 4096 bits | 384 bits |
| Security level | RSA 2048 ≈ 112 bits, RSA 4096 ≈ 140 bits | P-384 ≈ 192 bits |
| Handshake speed | Slow (large key, heavy computation) | Fast (small key, efficient) |
| Bandwidth | Larger certificate (256-512 bytes for key) | Small certificate (96 bytes for key) |
| Compatibility | All platforms | All modern platforms (Windows Vista+, Android 4+) |
We recommend ECDSA P-384 or RSA 3072 for new installations. P-384 provides faster handshakes than RSA, uses less bandwidth and has a security level equivalent to RSA 7680 bits. P-384 is still fast enough that the marginal speed difference compared to P-256 does not justify the lower security level. RSA 3072 is the obvious choice if you need RSA compatibility. Avoid RSA 2048, as it will be the first to become insufficient when requirements tighten.
The key type in the certificate is independent of the TLS connection's cipher suite. You can have an RSA certificate and still use ECDHE for key exchange (and thus forward secrecy). TLS 1.3 always requires ECDHE, regardless of certificate type.
Certificate lifetime and renewal
Certificates have a limited technical lifetime. CA/Browser Forum, the international body that sets the rules for the SSL industry, has adopted an aggressive reduction of the maximum lifetime:
The purpose of shorter lifetimes is to reduce the damage window if a key is compromised, and to force automation of certificate management. With 47-day certificates in 2029, manual renewal is not realistic for any infrastructure of meaningful size.
Automation via the ACME protocol is the answer. Read more about SSL automation and the full SSL lifetime timeline.
Level 3: For IT professionals
Cipher suites and forward secrecy
A cipher suite is the specific combination of algorithms used in a TLS connection: key exchange, signature algorithm, symmetric encryption and hash. TLS 1.3 cleaned up dramatically. Where TLS 1.2 had hundreds of possible combinations (many insecure), TLS 1.3 has only five:
Key exchange is not part of the cipher suite name in TLS 1.3, because it is always ephemeral Diffie-Hellman (ECDHE with X25519 or P-256, or DHE with ffdhe2048+). RSA key exchange has been removed entirely. This provides forward secrecy by default: each session uses unique, ephemeral keys. Even if the server's private key is compromised in the future, captured traffic cannot be decrypted retroactively. Intelligence agencies are known to collect encrypted traffic for future decryption ("collect now, decrypt later").
If you are still running TLS 1.2 (e.g. for compatibility with older systems), you should explicitly allow only secure suites and enforce forward secrecy. A good TLS 1.2 configuration allows only ECDHE-based suites with AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Avoid CBC mode (vulnerable to padding oracle) and RSA key exchange (no forward secrecy).
Cipher suites: What to use and what to avoid
| Cipher suite | Status | Note |
|---|---|---|
| TLS_AES_256_GCM_SHA384 | Recommended | TLS 1.3. Strongest default choice. |
| TLS_CHACHA20_POLY1305_SHA256 | Recommended | TLS 1.3. Fast on devices without AES-NI (mobile, ARM). |
| TLS_AES_128_GCM_SHA256 | OK | TLS 1.3. Mandatory in the standard. Acceptable security. |
| ECDHE-ECDSA-AES256-GCM-SHA384 | Acceptable | TLS 1.2. Best choice with ECDSA certificate. Forward secrecy + AEAD. |
| ECDHE-RSA-AES256-GCM-SHA384 | Acceptable | TLS 1.2. Best choice with RSA certificate. Forward secrecy + AEAD. |
| AES256-SHA256 | Avoid | RSA key exchange. No forward secrecy. Captured traffic can be decrypted if the key leaks. |
| ECDHE-RSA-AES128-SHA | Avoid | CBC mode. Vulnerable to padding oracle attacks (BEAST, Lucky13). |
| DES-CBC3-SHA | Dangerous | 3DES. Broken (Sweet32 attack). Never acceptable. |
| RC4-SHA | Dangerous | RC4 is fundamentally broken. Prohibited by RFC 7465. |
The pitfall of the "perfect" A+ configuration
It is tempting to harden your TLS configuration to allow only the newest and strongest cipher suites. In practice, an overly aggressive configuration can create real problems:
- Older email servers (Exchange 2010/2013, older SMTP relays) often only support TLS 1.0/1.1 with CBC ciphers. If your mail server rejects them, senders fall back to unencrypted SMTP, and your emails are sent in plaintext.
- Older mobile phones (Android 4.x, older IoT devices) lack support for TLS 1.2 and AEAD ciphers. Users get an error page with no explanation.
- Payment gateways and API integrations often use older TLS stacks. A strict configuration can break critical business processes.
- Internal systems (printers, scanners, surveillance cameras) rarely run updated firmware and may only support older ciphers.
Our recommendation: Start with Mozilla's "Intermediate" profile from the SSL Configuration Generator. It provides a good balance between security and compatibility. Then harden gradually, based on what your clients actually support. Use logging to identify which cipher suites are actually in use before removing them.
An A+ score on SSL Labs is meaningless if half your users or integrations cannot connect. Security is about protecting communication, not collecting points in a test.
Use our SSL Scanner to check your configuration. For configuration tools: Mozilla's SSL Configuration Generator produces secure configurations for Apache, Nginx, HAProxy and more. On Windows, IIS Crypto is the easiest tool to harden TLS configuration on IIS and Remote Desktop. See also our guide to Mozilla SSL Configuration Generator.
Trust stores and root programmes
The entire PKI system's trust starts with root certificates pre-installed on your computer or device. These roots are maintained by four major programmes with their own rules and audits:
Used by Windows, Edge and all .NET applications. Updated via Windows Update. Requires annual WebTrust audit.
Used by macOS, iOS and Safari. Updated via OS updates. Strict requirements for CT logging.
Used by Firefox and many open source projects. The most transparent process. Many Linux distributions use Mozilla's roots.
Launched 2023. Chrome previously used the OS trust store, but now has its own. Requires Certificate Transparency and ACME support for new inclusions. Uses CCADB (Common CA Database) as shared infrastructure with Mozilla.
The choice of CA (certificate authority) matters. Not all CAs have roots in all trust stores, and not all roots have the same coverage across platforms. A weak root may mean your certificate does not work on older Android devices or in specific enterprise environments. FairSSL sells from DigiCert, GlobalSign and Sectigo because these three have the broadest and most stable root coverage.
Certificate Transparency (CT)
Certificate Transparency (RFC 6962) is a public, append-only log system where all issued SSL certificates are recorded. The system was proposed by Google in 2013, primarily motivated by the DigiNotar scandal in 2011, when a compromised CA issued fraudulent certificates for google.com among others. CT later helped expose Symantec's unauthorised certificate issuances (2015-2017), which led to Symantec's root being removed from all browsers.
All public CAs are required to log certificates in at least two to three independent CT logs before the certificate is valid. The CA receives a Signed Certificate Timestamp (SCT) from each log, which is embedded in the certificate (or delivered via OCSP stapling or TLS extension). Browsers require SCTs and reject certificates without them. Chrome requires at least two SCTs from different log operators.
You can monitor CT logs for your domain via crt.sh or Google's Transparency Report. It is free and shows all certificates issued for your domain. Set up monitoring for your domain.
OCSP, CRL and revocation
When a certificate needs to be revoked (compromised key, mis-issuance, domain ownership change), browsers and clients need to know. There are three mechanisms:
- CRL (Certificate Revocation List): A complete list of revoked certificates from the given CA. The browser downloads the list and checks the serial number. Lists can become large (several MB) and are typically updated every 1-24 hours. Scales poorly.
- OCSP (Online Certificate Status Protocol): The browser sends the certificate's serial number to the CA's OCSP responder and receives a signed response ("good", "revoked" or "unknown"). Real-time check, but creates a privacy problem (the CA can see which sites you visit) and an availability problem (what if the OCSP server is down?). Many browsers "soft-fail": if the OCSP server does not respond, they accept the certificate anyway.
- OCSP Stapling: The server itself fetches the OCSP response from the CA periodically (e.g. every 4 hours) and sends the signed response along with the certificate during the TLS handshake. The browser does not need to contact the CA. No privacy leak, no extra latency. Enable it with
ssl_stapling on;in Nginx orSSLUseStapling Onin Apache.
Our recommendation: Enable OCSP Stapling. It is the only revocation mechanism that actually works for all clients without privacy issues. The server delivers the proof proactively, and the client does not need to perform external lookups.
Revocation is effectively broken
Google Chrome checks neither CRL nor OCSP for ordinary certificates. Google's argument is that OCSP lookups allow CAs to track users' browsing patterns, and that soft-fail (accept the certificate if the OCSP server does not respond) makes the mechanism meaningless against active attackers.
Instead, Chrome uses its own CRLite list, which only covers the largest and most critical sites. The result is that revoking a certificate for an ordinary domain effectively does not protect Chrome users. The certificate still appears valid even after revocation. Firefox and other browsers still check OCSP/CRL, but with Chrome at over 65% market share, the majority of users are not protected.
This has concrete security implications: if your private key is compromised, an attacker can continue using the certificate against Chrome users even after you have revoked it with the CA. The certificate works until it expires.
Therefore you should:
- Avoid wildcard certificates at root level for critical domains. If
*.your-domain.comis compromised, you cannot revoke it effectively, and the attacker can impersonate any subdomain. - Ensure you can switch FQDN in an emergency. If you can point traffic to a new hostname, you can avoid a man-in-the-middle attack with the compromised certificate.
- Use short certificate lifetimes, but do not rely on them alone. Google's argument is that short lifetimes (47 days in 2029) reduce the damage window enough to make revocation unnecessary. We disagree. 47 days is plenty of time to cause serious damage, and even a few days with a compromised certificate can be catastrophic if the timing is right. Short lifetimes help, but do not replace real revocation.
Let's Encrypt phased out OCSP entirely in 2025. The trend is clear: the industry is moving towards short lifetimes as a replacement for revocation. This makes ACME automation even more critical.
CAA records: Restrict who can issue
DNS CAA records (Certification Authority Authorization, RFC 8659) are a simple mechanism that tells CAs whether they are permitted to issue certificates for your domain. All CAs are required to check CAA before issuing. If your CAA record only allows DigiCert, neither Sectigo, Let's Encrypt nor any other CA can issue for your domain.
The iodef record in the example is a notification system: if a CA not in your CAA list receives a request to issue a certificate for your domain, it must send a report to the specified email or URL. This alerts you to unauthorised issuance attempts, whether they succeed or not.
CAA is simple to set up and provides a strong security guarantee. Use FairSSL's CAA record generator to build your configuration.
HPKP (HTTP Public Key Pinning): Deprecated and dangerous
HPKP (RFC 7469) was an HTTP header that pinned specific public keys in the browser. When a user visited your site, the browser remembered which keys it had seen and rejected future connections with different keys for the entire pin period (typically 60 days).
The idea was to prevent man-in-the-middle attacks with fraudulent certificates: even if an attacker got a CA to issue a certificate for your domain, the browser would reject it because the key did not match the pinned one.
Why HPKP was removed
In practice, HPKP turned out to be more dangerous than the attacks it was meant to protect against:
- Self-lockout. A misconfiguration, a lost key pair or a CA switch could permanently lock all users out of your site for weeks or months. There was no way to undo an active pin.
- HPKP Suicide. Attackers could set a malicious pin on a compromised site and then remove the real key. The site became permanently inaccessible to all users who had received the pin.
- Ransomware vector. An attacker with temporary control of a server could set a pin to their own key and then demand a ransom to release the domain.
All browsers have removed HPKP. Chrome removed it in version 72 (January 2019), Firefox in version 72 (January 2020). Mozilla has removed HPKP from their Web Security Guidelines. If you are still sending HPKP headers, they cause no harm but have no effect.
The replacement is CAA records (see above). CAA provides similar protection against unauthorised certificate issuance, but without the risk of locking yourself out. CAA is enforced by the CAs (server-side), not by browsers (client-side), so a misconfiguration can be corrected without affecting users.
HSTS and preloading
HTTP Strict Transport Security (RFC 6797) is an HTTP header that instructs browsers to always use HTTPS:
Once the browser has received this header, it will never attempt an HTTP connection for the max-age period (here 2 years). This protects against SSL-stripping attacks (e.g. Moxie Marlinspike's sslstrip), where an attacker downgrades the connection from HTTPS to HTTP.
HSTS Preloading goes one step further: your domain is added to a list hardcoded into browsers. So even the very first visit uses HTTPS (the TOFU problem is eliminated). Apply via hstspreload.org.
Warning: Preloading is difficult to remove. The process to get off the list takes months and requires all browsers to ship an update. Make sure HTTPS works correctly on all subdomains (including internal ones) before applying. includeSubDomains is a requirement for preloading.
Automation with ACME
ACME (Automatic Certificate Management Environment, RFC 8555) is a protocol for automatic certificate issuance and renewal. Let's Encrypt popularised ACME from 2016, but the protocol is open and is used by commercial CAs such as DigiCert, GlobalSign and Sectigo. Through FairSSL's ACME server you get the DigiCert family and GlobalSign.
ACME validates domain ownership automatically via three challenge types:
- HTTP-01: The CA checks a specific file under
/.well-known/acme-challenge/. Requires port 80 open. Cannot be used for wildcard. - DNS-01: The CA checks a TXT record under
_acme-challenge.yourdomain.com. Requires DNS API access (or CNAME delegation). Can be used for wildcard. - TLS-ALPN-01: The CA connects to port 443 with a special ALPN extension. Used by Caddy and in situations where port 80 is blocked.
FairSSL offers ACME with AutoDNS validation: create a permanent CNAME redirect from _dnsauth.yourdomain.com to FairSSL's validation infrastructure. DNS validation is then handled automatically, without giving DNS API keys to your servers.
ACME Renewal Information (ARI, RFC 9773) is the latest extension: the CA can tell your ACME client exactly when it should renew, e.g. because a certificate is being revoked or an intermediate is being rotated. With 47-day certificates in 2029, renewal timing becomes critical. Read more about SSL automation with FairSSL.
Common errors and troubleshooting
The most frequent errors:
The server only sends the leaf certificate. Works in Chrome (which can find the intermediate via AIA), but fails in curl, Python, mobile apps and CI/CD pipelines. Solution: install the full chain.
The page uses HTTPS but loads images, scripts or stylesheets over HTTP. The browser blocks or downgrades security. Solution: all resources must use HTTPS or protocol-relative URLs.
The certificate is issued for www.your-domain.com, but the server also responds on your-domain.com (without www) which is not in the SAN field. Solution: include both names in the certificate, or use a redirect.
The server allows deprecated TLS versions. These have known vulnerabilities (BEAST, CRIME) and are not permitted under PCI DSS. All modern browsers have dropped support. Solution: disable TLS 1.0 and 1.1, allow only TLS 1.2 and 1.3.
Production sites typically get attention, but internal systems (admin panels, CI/CD, monitoring) are often forgotten. An expired certificate on an internal service can break the entire deployment pipeline. Solution: ACME automation on all services, not just public-facing ones.
Frequently asked questions about SSL
Find answers to the most common questions about SSL certificates and FairSSL.
Ready to create a free account?
Create a free account and issue your first certificate in under 10 minutes.