SSL Certificates and HTTPS Explained

IPAddress-Lookup.com · June 25, 2025

Every time you visit a website and see a small padlock next to the address, or notice that the URL begins with https:// instead of http://, you are relying on one of the most important pieces of technology on the modern internet: SSL/TLS encryption and the digital certificates that make it possible. These certificates quietly protect your passwords, credit card numbers, private messages, and browsing habits from anyone who might be listening on the network between you and the server. Yet for something so fundamental, the mechanics of SSL certificates and HTTPS remain a mystery to most people. This guide pulls back the curtain and explains, in plain language, exactly what SSL/TLS is, how the encryption works, what a certificate actually proves, and how your browser decides whether or not to trust a site.

What SSL and TLS actually are

SSL stands for Secure Sockets Layer, a protocol originally designed by Netscape in the mid-1990s to secure communication between web browsers and servers. The problem it solved was simple to state but hard to fix: the original web (HTTP) sent everything as plain, readable text. Anyone positioned between you and a website — a rogue Wi-Fi hotspot, an internet provider, a compromised router — could read or even alter the data flowing back and forth. SSL wrapped that traffic in a layer of cryptography so that it became meaningless to eavesdroppers.

SSL itself is now obsolete. SSL 2.0 and SSL 3.0 were found to contain serious security flaws and have been retired for years. The protocol that actually secures the web today is called TLS, or Transport Layer Security. TLS is the direct successor to SSL, and when people say "SSL certificate" they almost always mean a certificate used with TLS. The name simply stuck because it was familiar. The evolution looks like this:

• SSL 1.0 — never publicly released due to security defects.
• SSL 2.0 (1995) and SSL 3.0 (1996) — both now deprecated and disabled everywhere.
• TLS 1.0 (1999) — the first version under the TLS name; also deprecated today.
• TLS 1.1 (2006) — retired alongside 1.0.
• TLS 1.2 (2008) — still widely used and considered secure when configured correctly.
• TLS 1.3 (2018) — the current standard, faster and stripped of legacy weak algorithms.

TLS 1.3 was a major redesign. It removed dozens of outdated cipher options that had caused vulnerabilities, and it streamlined the connection setup so that secure sessions establish more quickly. Modern browsers negotiate the highest version both sides support, which in practice means TLS 1.2 or 1.3.

What an SSL certificate actually does

An SSL/TLS certificate performs two distinct jobs, and it is important to understand that they are separate. The first is encryption — scrambling the data so it cannot be read in transit. The second is authentication, or identity verification — proving that the server you are talking to genuinely belongs to the domain shown in the address bar, and not to an impostor who has intercepted your connection.

Encryption without authentication would be dangerous. You could have a perfectly encrypted connection to an attacker who is simply relaying your traffic while reading everything. The certificate solves this by binding a cryptographic key to a verified identity. When your browser accepts a certificate, it is confirming both that the connection will be private and that the other end is who it claims to be. Together these two guarantees are what make online banking, shopping, and logins safe.

Asymmetric versus symmetric cryptography

To understand how HTTPS works, you need two ideas from cryptography, and they are simpler than they sound.

Symmetric encryption uses a single shared secret key to both scramble and unscramble data. It is extremely fast and efficient, which makes it ideal for encrypting the large volume of data in an actual browsing session. The catch is obvious: both sides need the same key, and if you send that key over an insecure network, an eavesdropper can grab it.

Asymmetric encryption solves the key-sharing problem using a matched pair of keys: a public key that anyone can see, and a private key that the owner keeps secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa. This lets two strangers agree on a secret over an open channel. Asymmetric crypto is slow, however, so it is not used for the whole conversation.

HTTPS combines the best of both. It uses slow asymmetric cryptography briefly, at the start, to safely establish a shared secret, and then switches to fast symmetric encryption for the rest of the session. That negotiation is called the TLS handshake.

How HTTPS works: a walk through the TLS handshake

When you type a web address, your browser first resolves the domain name to an IP address — a process closely tied to how DNS works — and then opens a connection to that server. Before any web page is exchanged, the TLS handshake takes place. Here is what happens, step by step.

1. ClientHello. Your browser sends the first message. It lists the TLS versions it supports, the cipher suites (combinations of encryption algorithms) it can use, and a random value that will feed into key generation. Think of it as saying "here is who I am and here is what I can speak."
2. ServerHello. The server replies by picking the TLS version and cipher suite it will use from the browser's list, and sends its own random value. Both sides now agree on the rules of the conversation.
3. Certificate. The server presents its SSL/TLS certificate, which contains its public key and the identity information that a Certificate Authority has signed. This is the moment your browser checks that the certificate is valid, trusted, and issued for the domain you are visiting.
4. Key exchange. Using the public key from the certificate (or a modern key-agreement algorithm such as Elliptic Curve Diffie-Hellman), the two sides securely derive a shared secret. Crucially, an eavesdropper watching every message still cannot compute this secret, because the private key never leaves the server.
5. Session keys and finished. Both sides use the exchanged material and the two random values to generate the same set of symmetric session keys. They each send a "finished" message encrypted with these keys to prove the handshake succeeded. From this point on, the entire conversation is encrypted symmetrically — fast, private, and tamper-proof.

All of this typically completes in a fraction of a second. In TLS 1.3 the handshake was shortened to a single round trip, and returning visitors can sometimes resume even faster. The end result is a secure channel over which your actual HTTPS requests and responses travel.

Certificate Authorities and the chain of trust

A certificate is only as trustworthy as the entity that vouches for it. That role belongs to a Certificate Authority (CA) — an organization your browser and operating system have decided to trust in advance. When a website owner requests a certificate, the CA verifies their control of the domain (and sometimes their business identity) before signing the certificate with the CA's own key. That signature is what your browser checks.

Trust is organized as a chain with three links:

• Root certificate. The top of the chain. Root certificates are pre-installed in your browser and operating system in a "trust store." Their private keys are kept offline under heavy security because compromising one would undermine the entire system.
• Intermediate certificate. Roots do not sign website certificates directly. Instead they sign one or more intermediates, which then sign the actual site certificates. This keeps the precious root key isolated and allows a compromised intermediate to be revoked without disturbing the root.
• Leaf certificate. Also called the end-entity certificate, this is the one installed on the website itself. It is signed by an intermediate.

When your browser validates a site, it walks up this chain: the leaf is signed by an intermediate, the intermediate is signed by another intermediate or a root, and the root is one it already trusts. If every link checks out and the root is in the trust store, the certificate is accepted. This is called chain building, and a common cause of "not trusted" errors is a server that forgets to send its intermediate certificate, breaking the chain.

Certificate types

Not all certificates are the same. They differ in how rigorously the CA verifies the applicant, and in how many domains they cover. The table below summarizes the main types.

A key point for everyday users: from an encryption standpoint, DV, OV, and EV certificates are identical. They all provide the same strong protection for your data. The difference is purely in identity assurance. Once upon a time EV certificates displayed a green company name in the address bar, but browsers have largely removed that distinction, so most sites today use inexpensive or free DV certificates.

Wildcard and multi-domain certificates

A wildcard certificate uses an asterisk to cover every subdomain of a base domain — for example a single certificate for *.example.com protects www.example.com, shop.example.com, and login.example.com at once. A multi-domain certificate, sometimes called a SAN or UCC certificate, lists several completely different domain names in one certificate. Both reduce the number of certificates an administrator has to manage.

What is inside a certificate

A certificate is a structured document, and you can inspect every field. The most important ones are:

• Subject. The identity the certificate was issued to, primarily the domain name (Common Name).
• Issuer. The Certificate Authority that signed and issued the certificate.
• Validity period. The "not before" and "not after" dates between which the certificate is valid.
• Subject Alternative Names (SAN). The full list of domain names the certificate covers. Modern browsers rely on the SAN field, not the old Common Name, to match the site.
• Public key. The public half of the key pair, used during the handshake.
• Signature algorithm. The cryptographic method used by the CA to sign, such as SHA-256 with RSA or ECDSA.
• Fingerprint. A unique hash of the whole certificate, useful for identifying it exactly.
• Serial number. A unique identifier assigned by the issuing CA.

When your browser validates a site, it checks that today's date falls within the validity period, that one of the SAN entries matches the domain, that the signature is intact, and that the chain leads to a trusted root.

Certificate expiry and why lifetimes are short

Every certificate has an expiration date, and lifetimes have been shrinking dramatically over the years. Certificates that once lasted several years are now capped at around a year or less, with the industry moving toward even shorter validity measured in weeks. There are good reasons for this trend.

Shorter lifetimes limit the damage if a private key is stolen — a compromised certificate simply expires sooner, reducing the window an attacker can exploit. They also ensure that outdated cryptographic algorithms and revoked or mistakenly issued certificates cycle out of the ecosystem quickly. The trade-off is that administrators must renew far more often, which is why automation has become essential rather than optional.

What happens when a certificate is invalid

If any part of validation fails, your browser interrupts the connection with a full-page warning rather than a small icon. The common failure cases are:

• Expired certificate. The current date is past the "not after" date. This is the most frequent cause and usually means someone forgot to renew.
• Self-signed certificate. The certificate was signed by its own key rather than a trusted CA, so no chain of trust exists. Fine for internal testing, but browsers reject it for public sites.
• Name mismatch. The domain you visited does not appear in the certificate's SAN list — for example a certificate for one domain served on another.
• Untrusted issuer. The certificate chains up to a root that is not in your trust store, often because an intermediate is missing or the CA is not recognized.
• Revoked certificate. The CA has invalidated the certificate before its expiry, typically because of a key compromise.

In each case the browser shows a warning such as "Your connection is not private" and blocks the page by default. These warnings exist to protect you: a mismatched or untrusted certificate can be a sign of a genuine interception attack, so they should never be casually clicked through on a site handling sensitive data.

Free certificates and automatic renewal

One of the most important developments in web security was the arrival of free, automated certificates. Let's Encrypt, a nonprofit Certificate Authority, made DV certificates available at no cost and, just as importantly, fully automatable through a protocol called ACME (Automated Certificate Management Environment).

With ACME, a server can prove control of its domain, request a certificate, install it, and renew it before expiry — all without human involvement. This is precisely why short certificate lifetimes are practical: a certificate that renews itself every couple of months causes no operational pain. The combination of free issuance and automation is a major reason HTTPS went from a minority feature to the near-universal default across the web.

How to inspect a site's certificate

You do not need special software to examine a certificate. In any modern browser you can click the padlock icon in the address bar and choose the option to view certificate details, where you will find the subject, issuer, validity dates, SAN list, and fingerprint. This is a quick way to confirm you are on the genuine site and to check when a certificate expires.

For a faster and more detailed view — including the full certificate chain, the signature algorithm, and how many days remain before expiry — you can use an online tool. Our own SSL Certificate Checker tool lets you enter any domain and instantly see whether its certificate is valid, correctly chained to a trusted root, and how much time is left before it needs renewing. It is a simple way to catch a soon-to-expire certificate before it triggers a browser warning for your visitors.

Frequently asked questions

Is SSL the same as TLS?

Not exactly. SSL is the older protocol and is now obsolete, while TLS is its modern successor and what actually secures websites today. However, the term "SSL certificate" has stuck through habit, so in everyday use "SSL" and "TLS" are often used interchangeably even though the underlying technology is TLS.

Does the padlock icon mean a website is safe?

The padlock means your connection to the site is encrypted and the certificate is valid for that domain. It does not guarantee the site itself is honest or free of scams — even fraudulent sites can obtain free DV certificates. Treat the padlock as a sign of a private connection, not a seal of overall trustworthiness.

Are free SSL certificates as secure as paid ones?

Yes, in terms of encryption. A free DV certificate from a CA like Let's Encrypt provides the exact same strength of encryption as an expensive certificate. Paid OV and EV certificates add extra identity verification of the organization, but they do not make the encrypted connection any stronger.

Why do I get a certificate warning on some sites?

Certificate warnings appear when validation fails — most commonly because the certificate has expired, does not match the domain name, is self-signed, or chains to an untrusted authority. The warning is your browser protecting you, and on a site handling passwords or payments you should not bypass it without understanding why it appeared.

How long do SSL certificates last?

Modern public certificates typically last about a year or less, and the industry is steadily moving toward much shorter lifetimes. Short validity periods reduce the risk from stolen keys and force outdated cryptography out of use. Automated renewal through protocols like ACME makes frequent renewal effortless.

Can I check a certificate without visiting the site in a browser?

Yes. Online tools let you enter a domain name and view its certificate details, including the issuer, validity dates, the full trust chain, and days until expiry, without manually inspecting the padlock. This is handy for monitoring your own sites or verifying a domain before you visit it.