53 questions that come up across every category on this site, grouped by topic — each links to the full guide if you want the complete explanation.
Yes. Modern browsers flag any HTTP page as "Not Secure," HTTPS is a (small) Google ranking signal, and free automated certificates via Let's Encrypt mean there's no longer a cost or complexity trade-off to weigh. See Do I Need SSL Without Payments?
SSL is the original, now-deprecated protocol name; TLS is its modern successor and what every current "SSL certificate" actually uses under the hood. See SSL vs TLS.
Yes — encryption strength is identical regardless of price. Paid certificates add a longer warranty, more thorough identity validation (OV/EV), and vendor support, not stronger encryption. See Free vs Paid SSL.
They differ in how much the CA verifies before issuing: DV confirms only domain control, OV also verifies the organization exists, and EV involves the most thorough legal/operational vetting — though EV no longer gets distinct browser UI treatment. See DV vs OV vs EV Certificates.
Certificates now max out at 398 days (Let's Encrypt defaults to just 90), specifically to encourage automated renewal. Set up an ACME client once, covered in our How-To category, and this stops being something you think about.
Your certificate is signed by an intermediate, which is signed by a root your browser already trusts — that chain of signatures is what lets a browser trust a certificate from a company it's never seen before. See What Is the Chain of Trust?
A wildcard covers one domain and all of its direct subdomains (*.example.com); a multi-domain (SAN) certificate covers a specific list of unrelated hostnames you name explicitly. See Wildcard vs Multi-Domain.
Yes, as long as every server presents the exact same certificate and private key — common for a load-balanced setup. See Can Two Sites Share a Certificate?.
On any reasonably current server, the difference is a few milliseconds — negligible, and often offset by HTTP/2's performance gains, which require HTTPS. See Does SSL Affect Speed?.
Only that the connection is encrypted and the certificate matches the domain — nothing about whether the site itself is trustworthy or legitimate. See What the Padlock Icon Means.
Server Name Indication lets a server host many different certificates on one IP address by having the browser announce which hostname it wants before the certificate is sent. See What Is SNI?
ECC gives equivalent security at a much smaller key size, meaning faster handshakes — a reasonable modern default, though RSA remains fully supported and secure. See RSA vs ECC Key Lengths.
Update your Site Address and WordPress Address in Settings, then add a server-level redirect (not just a WordPress plugin) so every entry point is covered. Full walkthrough in HTTPS Redirect on WordPress.
Redirecting in the wrong order, creating a loop with a CDN or proxy that's already handling TLS, and forgetting to test the www/non-www variant are the big three. See Common .htaccess Redirect Mistakes.
Either is fine — what matters is picking one canonical version and redirecting every request to it consistently, including in your certificate's coverage. See WWW vs Non-WWW Redirects With HTTPS.
Usually a CDN or proxy set to "Flexible" SSL mode fighting with your origin server's own HTTP-to-HTTPS redirect — each side thinks the other should be handling encryption. See Fixing Redirect Loops After HTTPS.
Add the HTTPS version as its own property, submit its sitemap, and monitor both versions briefly to confirm Google is properly picking up the migration rather than treating them as separate sites. See Search Console After HTTPS Migration.
Done correctly (proper 301 redirects, updated sitemap, no mixed content) it shouldn't — and HTTPS is itself a minor positive ranking signal. Migrating carelessly, with broken redirects or duplicate content, is what actually causes SEO damage. See HTTPS Migration & SEO on a Large Site.
Yes — certificate installation, redirect rules, mixed content check, Search Console update, and a final live-site test, roughly in that order. See HTTPS Migration Checklist.
Test against a staging environment or a local hosts-file override first, checking every entry point (www, non-www, specific deep links) rather than just the homepage. See Testing HTTPS Redirects Before Launch.
You generally need TLS configured at both the CDN/proxy edge and, for full end-to-end encryption, at the origin server too — a two-layer setup that's easy to leave half-finished. See HTTPS Migration Behind a CDN or Proxy.
Yes, but plan for it in advance — keep the old HTTP configuration available and lower your DNS TTL before the migration so a rollback, if needed, propagates quickly. See Rolling Back an HTTPS Migration Safely.
Using OpenSSL, your server's control panel, or our own browser-based CSR Generator — all three produce the same thing, a signing request plus a private key you keep. Full walkthrough in How to Generate a CSR.
Install the renewed certificate alongside the old one, then reload (not restart) your web server — a graceful reload picks up the new certificate without dropping active connections. See Renewing Without Downtime.
Certbot installs its own scheduled task on most systems automatically, but explicitly verifying a cron entry (or systemd timer) exists, and testing with --dry-run, confirms it's genuinely working. See Automating Renewal With Certbot & Cron.
With OpenSSL command-line conversions, or our own browser-based SSL Converter, which handles PEM, DER, and PKCS#12 without needing anything installed. See Converting Certificate Formats.
openssl s_client -connect yourdomain.com:443 piped into openssl x509 -noout -enddate gives you the exact expiry instantly. See Checking Certificate Expiry From the Command Line.
Through your CA's account dashboard or ACME client's revoke command, specifying a reason — and you should issue a replacement with a fresh key pair immediately afterward. See How to Revoke a Certificate.
Revoke the associated certificate immediately and reissue with a fresh key pair — there's no way to recover a lost key, since it was never stored anywhere recoverable by design. See Recovering From a Lost Private Key.
Confirm HTTPS works flawlessly across every subdomain first, run HSTS with a full one-year max-age and includeSubDomains for a while, then submit to hstspreload.org. See Setting Up HSTS Preloading.
Add ssl_stapling on, configure a resolver, and point ssl_trusted_certificate at your CA's chain — then verify it's actually working with a direct OpenSSL check rather than trusting the config alone. See OCSP Stapling on Nginx.
TLS 1.2 and 1.3 only, modern AEAD cipher suites, and a configuration generated against Mozilla's current recommended preset rather than one copied from an old tutorial. See Configuring Strong TLS on Nginx.
A dedicated monitoring tool checking expiry on a schedule, separate from whatever renewal automation you already trust — a safety net specifically for when that automation silently breaks. See Setting Up Certificate Monitoring.
Copying the certificate, matching private key, and complete intermediate bundle, then verifying with an independent tool rather than assuming a file copy succeeded correctly. See Migrating a Certificate to a New Server.
Each one points at a specific, narrow cause — an expired certificate, a hostname mismatch, an incomplete chain — rather than being interchangeable "something's wrong" messages. See Common SSL Errors and What They Mean.
Find the specific HTTP resource still loading on an HTTPS page (usually visible directly in browser DevTools' console) and update that one reference to HTTPS. See Fixing Mixed Content Warnings.
Almost always a caching, propagation, or client clock issue rather than a genuinely expired certificate — check both an independent server-side tool and your own system clock. See Why Your Certificate Shows as Expired When It Isn't.
Your server isn't sending a complete certificate chain — the client can't trace your certificate back to a trusted root because an intermediate is missing. See Fixing "Unable to Get Local Issuer Certificate".
The certificate is valid, but doesn't list the exact hostname you're visiting in its Subject Alternative Name field — often after adding a new subdomain without reissuing. See Fixing ERR_CERT_COMMON_NAME_INVALID.
The certificate was issued by a CA your browser doesn't recognize — commonly a self-signed or internal-CA certificate, which is expected on private infrastructure but a red flag on a public site. See Fixing ERR_CERT_AUTHORITY_INVALID.
Client and server share no mutually supported combination of protocol version and cipher suite — each side works individually, they just can't agree on anything in common. See Fixing SSL Version/Cipher Mismatch.
Browsers are often more forgiving about an incomplete chain than strict client libraries — the fix is always completing the chain server-side, not relying on any one client's leniency. See Cert Works in Chrome, Fails in API Client.
Usually an SNI misconfiguration — the server isn't correctly matching that hostname to its intended certificate, often falling back to a default instead. See Fixing SNI Misconfigurations.
Running with -v for detailed output usually reveals the specific cause immediately — commonly a firewall change, a rate limit, or a validation method's requirement no longer being met. See Troubleshooting Certbot Renewal Failures.
Yes — certificate validation depends entirely on comparing the current date against the certificate's validity window, so a wrong clock can make a perfectly valid certificate appear expired or not-yet-valid. See Fixing Clock Skew SSL Errors.
It means the CA has explicitly invalidated that certificate, typically due to a suspected key compromise — never click through this specific warning. See Fixing "Certificate Revoked" Errors.
A 2014 vulnerability in OpenSSL that let an attacker read a server's memory remotely, exposing private keys and sensitive data across a huge share of the internet's HTTPS servers at the time. See The Heartbleed Bug.
By launching a nonprofit CA in 2016 built entirely around automated issuance via the ACME protocol, removing both the cost and manual-renewal friction that had kept HTTPS adoption low for years. See The Rise of Let's Encrypt.
Cryptographic research showed SHA-1 collisions were becoming computationally feasible, meaning it could no longer be trusted to guarantee a certificate hadn't been tampered with. See SHA-1 Deprecation History.
Browser vendors removed the distinct EV visual treatment after research showed most users didn't understand or even notice it — EV certificates still exist, they just look identical to DV/OV now. See The EV Green Bar's Removal.
A deliberate, gradually escalating campaign by Google to push the entire web toward HTTPS by default, rather than treating encryption as an opt-in feature. See History of Chrome's "Not Secure" Warning.
Shorter lifespans limit how long a compromised or misissued certificate stays dangerous, and they push the entire industry toward automated renewal instead of error-prone manual processes. See The Shrinking of Certificate Validity Periods.
A system of public, append-only logs recording every publicly trusted certificate issued, created after incidents of CAs mis-issuing certificates that went undetected for a long time. See The History of Certificate Transparency.