What Is an SSL Certificate? Why HTTPS Matters for Website Security

The padlock in the address bar is the first trust signal most visitors notice. Since 2012 I have built and taken over many websites, and the SSL certificate story tends to break in the same places. Teams buy or enable a certificate, then skip the redirects, the mixed content cleanup and the renewal monitoring. This guide explains what an SSL certificate is, how HTTPS works and what I check during a migration.

What is an SSL certificate and what does it do?

An SSL certificate is a digital file that proves a domain's identity and lets the browser encrypt traffic between visitors and your server. A trusted certificate authority signs it. The browser checks that signature, then opens an encrypted connection, and the address loads over HTTPS.

In short, the certificate does two jobs. First, it proves the visitor is really talking to your server. Second, it stops anyone on the network from reading or changing form data, passwords and card details in transit. Moreover, this protection covers every page, not only the checkout.

People still say "SSL", but the protocol in use today is TLS. The old name simply stuck. I use the phrase SSL certificate in this article because that is what readers search for. Technically, I mean a certificate that works with TLS.

What is the difference between SSL and TLS?

SSL was the name of the first encryption protocol, created in the 1990s. Because of serious flaws, every SSL version is now retired, and TLS replaced it. Modern browsers speak TLS 1.2 and TLS 1.3. The latest version, TLS 1.3, has its definition in IETF RFC 8446.

So why does this matter to you? The certificate itself does not depend on the protocol version. You use the same certificate with TLS 1.2 and TLS 1.3. The real decision sits in your server settings: you switch off old, weak protocols and keep the modern ones on.

• SSL 2.0 and SSL 3.0: insecure, should stay disabled.
• TLS 1.0 and TLS 1.1: formally deprecated by the IETF, so I recommend disabling them.
• TLS 1.2: still common and considered safe.
• Modern TLS 1.3: faster handshake and a simpler set of ciphers.

In other words, "we have an SSL certificate" is not the whole answer. You also need to know which protocols your server accepts. Asking your host for a screenshot of that setting is the quickest way to find out.

How does an HTTPS connection work, step by step?

HTTPS is simply HTTP carried over a TLS encrypted channel. When someone opens your site, the browser and server first run a short handshake. It takes milliseconds; however, a lot happens in the background.

1. The browser lists the protocol versions and ciphers it supports.
2. Then the server replies with its SSL certificate and the settings it picked.
3. Next, the browser checks that a trusted authority signed the certificate and that the name matches the domain.
4. Both sides agree on a session key that exists only for this connection.
5. From then on, all traffic flows encrypted with that key.

Step three is the critical one. If the certificate has expired, if the name does not match, or if the intermediate chain is missing, the browser shows a full page warning. Therefore, always test the chain after installation. A missing intermediate certificate is a sneaky fault: it works on some devices and fails on others.

On the other hand, TLS 1.3 cut the number of round trips in the handshake. As a result, a well configured HTTPS setup does not slow a site down in any meaningful way.

DV, OV or EV: which SSL certificate type do you need?

In practice, certificates fall into three classes based on how deeply the authority checks your identity. Still, the encryption strength is the same in all three. The difference lies only in the validation scope.

EV certificates used to show a green company name in the address bar. However, the major browsers removed that special display. Today a visitor can only see the difference between DV and EV by clicking into the certificate details.

That is why a DV certificate is enough for most of my clients. OV or EV only makes sense when a tender, a bank integration or an internal audit demands it.

Single domain, wildcard or multi domain: how do you choose?

Apart from validation type, coverage matters too. A wrong choice here means a warning screen on the day you launch a new subdomain.

• Single domain: for example yourdomain.com plus the www version. Enough for small sites.
• Wildcard: covers every first level subdomain, written as *.yourdomain.com. Handy if you run a blog, a shop and a portal on subdomains.
• Multi domain (SAN): groups several different domains into one certificate. Useful for companies that manage multiple brands or country domains.

A wildcard looks convenient, but it carries a risk: every subdomain shares the same private key. If an attacker compromises one subdomain server, the key can put the others at risk. For that reason, I give sensitive subdomains, such as payment or admin areas, their own certificate.

Also, if your business email runs on the same domain, plan the mail server certificate separately. I covered that setup in the guide on business email with a custom domain.

Is a free SSL certificate safe to use?

Yes. A free certificate from a trusted authority gives the same encryption as a paid DV certificate. The best known example is Let's Encrypt, a nonprofit certificate authority. In addition, most hosting panels install it with one click and renew it automatically.

Let's Encrypt only issues DV certificates; it does not offer OV or EV. According to its official FAQ, its certificates last 90 days and Let's Encrypt designed them for automated renewal. A short lifetime looks like a drawback at first. In practice, it limits the damage if a key ever leaks.

What does a paid certificate add? Usually an OV or EV option, phone support and sometimes a warranty. That said, warranty payouts rarely happen in real life. Put simply, a free certificate is not a cheap compromise for most sites. It is the right choice.

My one condition: test that renewal really runs on its own. If automated renewal breaks quietly, the certificate expires one night and your site opens with a warning the next morning.

Why are SSL certificate lifetimes getting shorter?

The CA/Browser Forum, the body where certificate authorities and browser makers set shared rules, voted to shorten the maximum lifetime of public certificates in stages. Under the adopted schedule, the limit drops first to 200 days, then to 100 days, and to 47 days in 2029.

The logic is simple, because risk scales with time. The shorter the lifetime, the smaller the window in which a stolen or wrongly issued certificate can cause harm. On the other hand, teams that renew by hand face a real workload. A yearly task becomes something you repeat several times a year.

So my advice is clear: automate renewal now. An ACME client or your hosting panel's auto renewal feature handles it. If you buy paid certificates, ask your vendor whether they support ACME.

• Keep every certificate and its expiry date in one list.
• Set up monitoring that alerts you at least 14 days before expiry.
• After each renewal, check the chain and the name match automatically.

Does Google use HTTPS as a ranking signal?

Yes. Google announced on its Search Central blog in 2014 that HTTPS had become a lightweight ranking signal. Later, HTTPS remained part of the page experience signals. Still, Google states clearly that this signal does not outrank content quality.

What does that mean in practice? Moving to HTTPS will not make your rankings jump. However, a site still on HTTP carries a small and needless handicap against an equal competitor. Also, HTTPS is a trust and conversion issue that exists regardless of search engines.

From an SEO angle, the real risk is not HTTPS itself. It is a badly managed migration. Wrong redirects, both versions indexed at once, or canonical tags left on HTTP cause the actual ranking losses. That is why I treat HTTPS as part of the core technical SEO checks.

How do browsers treat a site without an SSL certificate?

Starting with Chrome 68 in 2018, Chrome labels HTTP pages as "Not secure" in the address bar. Other major browsers show similar warnings. The label becomes more prominent on HTTP pages that contain forms.

In practice, this warning is a silent conversion leak. Visitors who leave never tell you why. For example, someone who sees "Not secure" next to a quote form may decide not to type their phone number.

An expired certificate is worse. In that case the browser does not load the page at all; it shows a full screen warning instead. Most visitors stop there. Meanwhile, your ad budget keeps running, and paid clicks land on a warning page. In the accounts I run through Google Ads management, I therefore treat certificate monitoring as seriously as budget checks.

What steps should you follow to move from HTTP to HTTPS?

For Google, a switch to HTTPS is a site move with URL changes. Google's site move guide handles it with the same logic. Here is the order I follow:

1. Install the SSL certificate and test that every page loads cleanly over HTTPS.
2. Switch all internal links, image and script URLs to HTTPS.
3. Update canonical, hreflang and Open Graph tags to the HTTPS addresses.
4. Set up page level 301 redirects from HTTP to HTTPS.
5. Rebuild the XML sitemap with HTTPS URLs only.
6. Verify the HTTPS property in Search Console and submit the sitemap.
7. Update the site URL in analytics, ad platforms and marketing tools.

Most of this list overlaps with a redesign. If you combine HTTPS with a new design, keep the website migration checklist open as well. The guide on protecting SEO during a redesign covers the rest.

How can you tell you set up your 301 redirects correctly?

A correct setup sends every HTTP URL, in one hop, with a permanent 301 status, to the same path on HTTPS. Redirecting everything to the homepage is the most common mistake I see. As a result, it wastes the value that deep pages have built up.

Also watch for redirect chains. For example, if http://yourdomain.com first goes to http://www and only then to https://www, you get a two step chain. Chains slow pages down and waste crawl effort. The goal is one hop to the final URL, whatever variant the visitor started from.

• Test the http:// and http://www variants separately.
• Try URLs with and without a trailing slash.
• Check that query strings survive the redirect.
• Confirm the status code is 301, not 302.

Doing this by hand in a browser gets tiring fast. Instead, a redirect checker shows how many hops each URL takes and where it ends. Combine that with the internal linking review so your own links point straight to HTTPS.

What does mixed content mean and how do you fix it?

Mixed content happens when a page loads over HTTPS but still requests some resources over HTTP. Images, scripts, stylesheets and iframes are typical examples. According to web.dev, browsers block active mixed content, such as scripts and stylesheets, by default.

As a result, the page loads but a menu stops working, a form fails to submit or the layout breaks. For passive content like images, the browser tries to upgrade the request to HTTPS. If that fails, the image simply does not show. The padlock can also lose its clean state.

My cleanup order looks like this:

• Collect "Mixed Content" warnings from the browser console, page by page.
• Search the database for hardcoded http:// URLs and replace them.
• Change fixed URLs in theme and plugin files to relative or HTTPS versions.
• Use the HTTPS version of third party scripts, or remove scripts that lack one.

Always take a backup before a bulk database replace. In particular, content systems that store serialized data can break under a plain text search and replace.

What is HSTS and when should you turn it on?

HSTS is a security header in which the server tells the browser: "from now on, connect to this domain only over HTTPS." The browser remembers that instruction for the period you set. So even if a user types http://, the browser upgrades the request itself.

This header reduces the risk that someone intercepts that first HTTP request. It also removes the redirect step, so it, which saves a little time. However, do not rush it, because HSTS is hard to undo.

The order I recommend:

1. First, confirm that every subdomain works over HTTPS.
2. Start with a short max age, for example a few minutes.
3. If nothing breaks, raise the value step by step.
4. Add the subdomain option only after you have checked all of them.

Joining the browser preload list is close to permanent. Getting removed can also take weeks. Therefore, take that step only when you are fully sure of your HTTPS setup.

Where do you get an SSL certificate and how do you install it?

In practice there are three routes. The first is the automatic certificate in your hosting panel. Panels like cPanel and Plesk usually work with Let's Encrypt or a similar authority and install the certificate without any effort from you. For most small and mid sized sites, that is enough.

The second route is a paid certificate from a vendor. You create a key pair and a certificate signing request (CSR) on the server. Then you send the CSR, pass validation and upload the issued files. The third route is a certificate from your CDN provider, which encrypts the link between visitors and the CDN.

• Choose DNS record or file upload for domain validation.
• Never share the private key over email.
• After installation, open every variant in a browser.

Whatever route you pick, know who holds the private key. If that knowledge disappears when you change agency or developer, renewal day can turn into a crisis.

How should you handle HTTPS on a site behind a CDN?

With a CDN you really have two connections: visitor to CDN, and CDN to your server. However, many sites encrypt only the first one. The padlock appears, but data travels part of the way to your server unencrypted.

That is why I recommend the "full" or "strict" encryption mode in the CDN panel. In strict mode, the CDN also checks that the certificate on your server is valid. If the server has no valid certificate, install one first, then switch the mode. Otherwise, your site will show an error.

Also, keep redirect rules in one place. If you write the HTTP to HTTPS redirect in the CDN, the server and the application, the chance of loops and chains goes up. I usually handle it at the CDN layer and leave only a fallback rule on the server.

What should you monitor in Search Console after the move?

First, note that the weeks after the switch are the cheapest time to catch errors. Google treats HTTP and HTTPS addresses as separate URLs. So if you use a domain property, watch both versions together. If you use a URL prefix property, add and follow the HTTPS property.

• In the page indexing report, watch HTTP URLs fall and HTTPS URLs rise.
• Check that the "Page with redirect" count stays where you expect.
• Compare submitted and indexed counts in the sitemap report.
• Confirm in the performance report that clicks move to the HTTPS version.

If these reports are new to you, the Search Console guide helps. A few months later, also check whether old HTTP URLs still get traffic. You can ask site owners who link to you to update their links; that way you depend less on redirects.

Do subdomains and old URLs get forgotten during the switch?

Yes, this is the part teams skip most often. The main site moves to HTTPS, but a campaign subdomain from years ago, an old blog or a staging server stays on HTTP. Those addresses create a security gap and a poor first impression for the brand.

Before the switch, list every subdomain you own. In practice, your DNS records are the most reliable source for that list. Shut down the ones you no longer use and add the rest to your certificate coverage. In addition, update URLs in email signatures, printed catalogues and social profiles, because visitors often make their first click there.

In short, do not stop at the main domain. Every address your brand touches should meet the same trust standard.

Does an SSL certificate speed up or slow down your site?

A well configured SSL certificate does not slow a modern site down in any noticeable way. In fact, HTTPS can make it faster, because browsers only use faster protocols like HTTP/2 and HTTP/3 over HTTPS in practice.

Instead, slowness usually comes from somewhere else. For example, a missing intermediate chain triggers extra lookups on some devices. Redirect chains add a delay at every hop. If session resumption is off on the server, repeat visitors go through the full handshake each time.

That is why I rerun speed tests after an HTTPS move. The steps in the Lighthouse performance test guide apply here too. I explain the ranking side in the article on how site speed affects SEO.

Does an SSL certificate alone make your site secure?

No. An SSL certificate protects data in transit only. It says nothing about the server, the software, the passwords or the plugins. Therefore, a site with a padlock can still host malware or be a fake.

In fact, many phishing sites use HTTPS today, because DV certificates are easy and free to get. So telling people "the padlock means it is safe" is no longer good advice. The padlock means "this connection uses encryption". It does not mean "this site is honest".

For real security, look beyond the certificate:

• Keep the CMS, theme and plugins up to date.
• Use strong passwords and two factor authentication for the admin area.
• Run regular backups and store them off the server.
• Limit server access with the least privilege principle.

Planning security headers and redirects at the build stage is the cheapest option. I include that in web design projects from day one.

How do you diagnose and fix common SSL certificate errors?

Most SSL certificate errors I meet in the field fall into five groups. Each has a different symptom, so first read the error carefully first.

Specifically, the last one shows up often on sites behind a CDN or proxy. For example, if the CDN connects to the server over HTTP while the server forces HTTPS, you get a loop. The fix is to encrypt the CDN to server link as well.

Why is an SSL certificate critical for ecommerce and lead forms?

Any page that collects personal data or payment details faces real exposure without encryption. PCI DSS, the card industry standard, requires strong cryptography for card data in transit. Data protection laws such as the GDPR also expect appropriate technical measures.

That said, compliance is only part of the story. After all, lost trust at the payment step means abandoned carts. Contact and quote forms also carry names, phone numbers and email addresses. Consequently, "we have no checkout, so we do not need it" is a flawed argument.

On ecommerce projects, I turn on HTTPS on day one, not as a layer added later. If you want to plan the store, payments and trust elements together, see ecommerce consulting. To raise trust in your forms, apply the ideas in the lead form design guide.

What should your SSL certificate checklist include?

I use this list when I launch a new site or take over an existing one. Check each item once and log it in a sheet. Consequently, that habit removes most future surprises.

• Does the certificate cover every domain variant?
• Is the intermediate chain complete?
• Does auto renewal work, and does a monitor track it?
• Are old protocols (SSL, TLS 1.0 and 1.1) disabled?
• Is there a one hop 301 redirect from HTTP to HTTPS?
• Do canonical tags, hreflang and the sitemap point to HTTPS URLs?
• Are any mixed content warnings left in the console?
• Is HSTS live, rolled out in planned stages?

Repeat this list after every major update, not once a year. A new plugin or theme change can quietly bring mixed content back.

In short, an SSL certificate is not a product you buy and forget. It is a piece of infrastructure that needs regular care. If you want the post migration side watched as well, I track it within SEO consulting.