LiveChat 
Support 
SSL Certificates: The Complete Guide to How HTTPS Encryption and Trust Work
The small padlock in your browser’s address bar represents one of the most quietly important pieces of infrastructure on the modern web. Behind it sits an SSL/TLS certificate doing two jobs at once, billions of times a day, on every banking login, checkout page, and ordinary blog. Most explanations stop at “it makes your site secure,” which is true but unhelpfully vague. This guide goes a layer deeper: it explains the *mechanism*, so that by the end you can reason about certificates instead of memorizing rules.
This is a hub page. Each section gives you the practical understanding you need, then points to a deeper article. Read it top to bottom for a full mental model, or jump to the section that matches the problem in front of you.
Key Takeaways
• An SSL/TLS certificate does two distinct jobs: it encrypts the connection (privacy) and authenticates the site’s identity (proving you reached the real server, not an impostor).
• The encryption strength is identical across every certificate type. Paying more for OV or EV buys a *stronger identity proof*, not stronger encryption.
• “SSL” is the everyday name; the protocol actually running today is TLS. The old SSL versions are deprecated and insecure.
• Trust flows through a chain: a publicly trusted root certificate authority (CA) vouches for an intermediate, which signs your site’s certificate.
• Free certificates (Let’s Encrypt, AutoSSL) provide exactly the same encryption as paid ones. Automation, not cost, is the real differentiator today.
What is an SSL/TLS certificate, and why two names?
An SSL certificate is a small data file that binds a cryptographic key pair to a verified identity, usually a domain name. When installed on a web server, it lets that server prove who it is and establish an encrypted channel with visitors. The padlock, the `https://` prefix, and the absence of “Not secure” warnings are all downstream consequences of one being present and valid.
The naming is a historical accident worth clearing up. SSL (Secure Sockets Layer) was the original protocol from the 1990s. It was succeeded by TLS (Transport Layer Security), and every version of SSL has since been deprecated as insecure. The protocol your browser negotiates today is TLS 1.2 or TLS 1.3, never SSL. But the term “SSL certificate” stuck so firmly in marketing and habit that the industry still uses it. So when you read “SSL certificate,” mentally translate it to “the certificate used by TLS.” The file and the math are the same; only the label is dated.
For the full history of the protocol and how the SSL-to-TLS transition unfolded, see . For where TLS sits in the broader stack, see .
How does SSL actually work? The two jobs and the handshake
This is the most important section, because almost every SSL decision becomes obvious once you understand that a certificate has two separable jobs.
Job one is encryption. It scrambles the data flowing between browser and server so that anyone intercepting it on the network, a coffee-shop Wi-Fi sniffer, a rogue router, an ISP, sees unreadable ciphertext instead of passwords and credit card numbers.
Job two is authentication. It proves that the server you connected to genuinely controls the domain in the address bar. Encryption alone is worthless without this: you could have a perfectly encrypted connection to an attacker who tricked your DNS. Authentication is what guarantees the encrypted tunnel actually terminates at the real site.
These two jobs are accomplished together during the TLS handshake, the brief negotiation that happens before any real data is exchanged. Here is the mechanism, simplified but accurate:
- Client hello. Your browser connects and lists the TLS versions and cipher suites it supports.
- Server hello and certificate. The server replies with its chosen cipher and sends its certificate, which contains its public key and its verified identity, signed by a certificate authority.
- Authentication. The browser checks the certificate: Is it signed by a CA the browser trusts? Does the domain match? Has it expired? Was it revoked? If any check fails, you get a warning instead of a padlock. This step is job two.
- Key exchange. Using asymmetric cryptography, browser and server agree on a fresh, shared session key that no eavesdropper can derive. In TLS 1.3 this happens in a single round trip, which is why modern HTTPS is fast.
- Encrypted session. From here on, both sides switch to fast symmetric encryption using the session key. This is job one.
The elegant part is the split between asymmetric and symmetric cryptography. Asymmetric math (slow but able to establish trust between strangers) is used only briefly to authenticate and agree on a key. The bulk transfer then uses symmetric encryption (fast). You get the trust properties of public-key cryptography with the speed of symmetric ciphers.
For a step-by-step walkthrough of every message in the negotiation, see .
Here is the insight that clarifies every certificate decision you will ever make: the encryption is identical across all certificate types. A free Let’s Encrypt certificate and a four-figure Extended Validation certificate negotiate the exact same TLS 1.3 ciphers and produce the exact same unbreakable session key. The padlock means the same thing cryptographically in both cases. What more expensive certificates buy is a *stronger answer to job two*, a more rigorously vetted statement of *who* is on the other end. People constantly conflate “more expensive SSL” with “stronger security,” but encryption strength is a property of the protocol, not the price tag. Once you internalize the encrypt-versus-authenticate split, the entire market for certificate types makes sense: you are never shopping for stronger locks, you are shopping for stronger identity proof.
What is the chain of trust, and who are the CAs?
Your browser cannot personally know every website on earth. Instead, trust is delegated through a chain. Understanding it explains most “certificate not trusted” errors.
There are three links:
- Root certificate. A small set of root CAs whose certificates ship pre-installed in your operating system and browser. These are the anchors of trust. Their private keys are guarded in offline hardware and almost never used directly.
- Intermediate certificate. Roots sign intermediate certificates, which do the day-to-day work of issuing certificates. This keeps the precious root key offline and limits damage if an intermediate is compromised.
- Leaf certificate. Your site’s actual certificate, the leaf or end-entity certificate, signed by an intermediate.
When a browser validates your site, it walks the chain upward: leaf to intermediate to root. If every signature checks out and the chain terminates at a root the browser already trusts, the connection is authenticated. A certificate authority (CA) is simply an organization permitted to issue certificates that chain back to a trusted root. Let’s Encrypt is a widely trusted nonprofit CA whose root and intermediates are recognized by essentially every modern browser, which is why its free certificates are treated identically to commercial ones.
The single most common installation mistake is a broken or incomplete chain: the server sends the leaf certificate but forgets to include the intermediate. The leaf is valid, but the browser cannot connect it to a trusted root, so it throws an error. For how the chain is assembled and how to diagnose a missing intermediate, see .
What are the SSL certificate types: DV, OV, and EV?
Certificate types differ entirely in job two, identity validation, not in encryption. They answer the question “how thoroughly did the CA verify who is requesting this certificate?”
| Type | What is validated | Issuance time | What the visitor sees | Best for |
|---|---|---|---|---|
| DV (Domain Validation) | Control of the domain only (via DNS, email, or file) | Seconds to minutes | Padlock | Blogs, personal sites, most small business sites |
| OV (Organization Validation) | Domain control plus the legal existence of the organization | Hours to days | Padlock; org details in certificate | Business and corporate sites wanting verified identity |
| EV (Extended Validation) | Rigorous legal, physical, and operational verification of the organization | Days to weeks | Padlock; org name in certificate details | Banks, large e-commerce, high-trust brands |
A crucial point that surprises many people: modern browsers no longer display the green company name in the address bar for EV certificates. That visual distinction was removed years ago because studies showed users did not notice or rely on it. EV’s organizational proof now lives inside the certificate details, where most visitors never look. This makes EV harder to justify for the average site, the encryption is identical and the once-prominent visual reward is gone.
For the practical differences and when each is worth it, see . For the validation process itself, see .
You should also know about coverage scope, which is separate from validation level. A standard certificate covers one hostname. A wildcard certificate covers all subdomains of a domain (`*.example.com`). A multi-domain (SAN/UCC) certificate covers several distinct domains in one file. See .
Free vs paid SSL: which should you choose?
Because encryption is identical, the free-versus-paid question reduces to identity needs, automation, and support, never to “is it secure enough.” Free, automated DV certificates now secure a majority of the web.
| Factor | Free SSL (Let’s Encrypt, AutoSSL) | Paid SSL |
|---|---|---|
| Encryption strength | Identical (TLS 1.2/1.3) | Identical (TLS 1.2/1.3) |
| Validation levels | DV only | DV, OV, EV |
| Typical validity | 90 days (renewed automatically) | Up to ~398 days |
| Renewal | Fully automated | Often manual unless tooled |
| Warranty / support | Community / host-provided | Vendor warranty and support |
| Cost | $0 | Tens to thousands per year |
Let’s Encrypt is the dominant free CA. Its 90-day certificate lifetime sounds inconvenient but is deliberately short to force automation; a certificate that renews itself every 60 days is far safer than one a human forgets to replace after a year. AutoSSL, built into cPanel, automatically issues and renews free certificates for every domain on a server with zero manual steps, the model most shared hosting uses.
Paid certificates make sense when you need OV or EV identity validation, a warranty, or formal vendor support, not when you simply want a working padlock. For the full cost-benefit breakdown, see and .
How do you get and install an SSL certificate?
Installation has two broad paths depending on how much control your environment gives you.
The managed path (shared hosting / cPanel). With AutoSSL, you usually do nothing. The control panel detects each domain, requests a DV certificate from a CA, installs it with the full chain, and configures the server. If you need to install a certificate you obtained elsewhere, cPanel’s SSL/TLS manager lets you paste the certificate, key, and CA bundle into a form. See .
The self-managed path (VPS / dedicated server). With root access you control the web server directly. The standard modern tool is Certbot, the official Let’s Encrypt client. A single command (`certbot –nginx` or `certbot –apache`) proves domain control via the ACME protocol, fetches a certificate, writes it to disk, edits your server config, and installs a renewal timer. The ACME challenge is how the CA verifies job two automatically: it asks your server to serve a specific token, proving you control the domain before issuing. See and .
Whichever path you take, the install is only correct if the server presents the leaf plus the intermediate chain. A certificate that validates in your browser but fails in older clients is almost always a missing-intermediate problem, which is why automated tooling that bundles the chain for you removes a whole class of bugs.
How do you manage SSL certificates over time?
A certificate is not “install once and forget.” It has a lifecycle, and the discipline that matters most is renewal before expiry, because an expired certificate breaks job two and every visitor gets a full-page security warning.
The key practices:
- Automate renewal. Certbot installs a timer; AutoSSL runs on a schedule. Automated renewal is the single most effective reliability practice in SSL, because the failure mode of manual renewal is a human forgetting. See .
- Monitor expiry. Even with automation, watch certificate dates so a silent renewal failure does not surprise you. Expiry monitoring catches the case where automation broke months ago and nobody noticed.
- Replace and rotate cleanly. When you change keys, switch CAs, or migrate servers, you replace the certificate. Done carelessly this causes downtime; done correctly it is seamless. See .
- Remove certificates safely. Decommissioning a domain or undoing a misconfiguration sometimes means removing a certificate, which must be paired with correct redirect handling so visitors are not stranded. See .
The short Let’s Encrypt lifetime reframes management as an automation problem rather than a calendar problem, and that is the healthier way to think about it.
What are the most common SSL errors, and how do you fix them?
Most SSL errors trace back to one of the two jobs failing. Either authentication broke (job two) or the protocol negotiation could not complete. Here are the recurring ones:
- Certificate expired or not yet valid. The most common error, and entirely an automation failure. The fix is renewal plus monitoring.
- Name mismatch. The certificate’s domain does not match the address visited (for example, a certificate for `example.com` served on `www.example.com`). Fix the certificate’s coverage or the redirect.
- Incomplete chain / untrusted issuer. The intermediate is missing, so the browser cannot reach a trusted root. Install the full chain. See .
- Mixed content. The page loads over HTTPS but pulls images, scripts, or styles over plain HTTP. The browser blocks or downgrades them and the padlock breaks. The fix is to serve every resource over HTTPS. See .
- Protocol or cipher mismatch. Client and server share no acceptable TLS version or cipher, common with very old clients or misconfigured servers. See .
- Plain HTTP sent to an HTTPS port. A configuration or proxy mismatch where unencrypted traffic hits port 443. See .
For a structured approach to diagnosing any HTTPS failure from symptom to root cause, see .
Which ports and services does SSL apply to?
SSL/TLS is not limited to websites. It secures any protocol that opts into it, and knowing the ports demystifies a lot of configuration.
| Service | Plain port | TLS-secured port |
|---|---|---|
| Web (HTTP/HTTPS) | 80 | 443 |
| IMAP (incoming mail) | 143 | 993 |
| POP3 (incoming mail) | 110 | 995 |
| SMTP (outgoing mail) | 25 / 587 | 465 (or 587 with STARTTLS) |
Port 443 is the one everyone knows, the default for HTTPS, and the reason `https://example.com` needs no port number. Email is the other major consumer of TLS: your mail client negotiates the same kind of handshake to encrypt messages in transit. Two models exist, implicit TLS (the connection is encrypted from the first byte, as on port 443 or 993) and STARTTLS (the connection starts plain, then upgrades), but both rely on the same certificates and the same trust chain.
For the port reference in depth, see . For how these ports fit into firewalls and routing, see .
Why does every website need SSL now?
A decade ago SSL was optional, reserved for login and checkout pages. Today it is effectively mandatory, for three concrete, grounded reasons rather than vague “best practice.”
Browsers actively warn against unencrypted sites. Modern browsers label any plain-HTTP page as “Not secure,” and increasingly interrupt with a full warning before loading it. To a visitor, that warning reads as “this site is dangerous,” regardless of what the page actually contains. Without a certificate, you are not neutral; you are flagged.
Search engines reward HTTPS. Google has used HTTPS as a ranking signal for years, and its crawlers and indexing favor secure pages. An unencrypted site competes at a disadvantage in search.
Trust and function depend on it. Visitors look for the padlock before entering anything. Beyond perception, many modern web features, HTTP/2 and HTTP/3, service workers, geolocation, and others, simply refuse to run without HTTPS. SSL has become a prerequisite for the modern web platform, not an add-on. See .
The bottom line: the cost of *not* having SSL, lost rankings, browser warnings, broken features, and eroded trust, now vastly outweighs the near-zero cost of getting it.
How DarazHost handles SSL for you
Everything above describes work that, on many platforms, you would have to do by hand. DarazHost removes that burden entirely.
Every DarazHost plan includes free SSL certificates auto-installed on every domain, powered by AutoSSL. That means each site you host gets a valid certificate with the complete chain (no missing-intermediate errors), automatic renewal well before expiry (no calendar to remember, no expired-certificate warnings), and the padlock, encryption, and browser trust working from day one, at zero cost and zero hassle.
For users who want full control, DarazHost VPS plans include root access so you can run Certbot, install certificates you obtained elsewhere, configure custom cipher suites, and manage the certificate lifecycle yourself. And whichever path you take, 24/7 SSL support is available to help diagnose chain issues, mixed content, protocol errors, or anything else on this page.
In short: DarazHost gives you the automated, correct-by-default SSL setup that this guide recommends, while still leaving the door open to do everything manually if you prefer. See .
Frequently asked questions
Is a free SSL certificate as secure as a paid one? Yes, for encryption. A free Let’s Encrypt certificate negotiates the same TLS versions and ciphers as the most expensive certificate, producing identical encryption. The difference is in identity validation (job two) and support, not in the strength of the encryption (job one).
What is the difference between SSL and TLS? TLS is the modern successor to SSL. Every version of SSL is deprecated and insecure; the protocol actually running today is TLS 1.2 or TLS 1.3. “SSL certificate” is just the popular name that survived the transition. The certificate file and cryptography are the same regardless of which term you use.
Why do certificates expire, and why are some only 90 days? Short lifetimes limit the damage if a key is ever compromised and force the renewal process to be automated rather than dependent on someone’s memory. Let’s Encrypt’s 90-day certificates are designed to renew themselves automatically, making them more reliable in practice than a manually managed one-year certificate.
My site shows “Not secure”, what does that mean? It means the browser detected no valid SSL certificate (or a broken one) on the connection. Either no certificate is installed, it has expired, the chain is incomplete, or the page is mixing HTTP and HTTPS content. Installing a valid certificate and serving all resources over HTTPS resolves it.
Do I need SSL if my site does not collect payments or logins? Yes. Browsers flag every plain-HTTP page as “Not secure,” search engines favor HTTPS, and many modern web features refuse to run without it. SSL is now a baseline requirement for any public website, not just transactional ones.
What does the padlock icon actually guarantee? It guarantees that the connection is encrypted and that the certificate is valid and trusted for the domain you visited. It does *not* guarantee the site is run by an honest business, a phishing site can have a valid DV certificate. The padlock confirms the connection is private and reaches the stated domain, not that the people behind the domain are trustworthy.
