What Is an SSL Certificate and Why Does Your Website Need One?

Overview

An SSL certificate (technically TLS these days, but everyone still says SSL) is a small digital file installed on your server that does two things: it encrypts traffic between your server and a visitor’s browser, and it verifies that your site is actually who it claims to be. When SSL is active, your site loads over HTTPS instead of HTTP, and visitors see a padlock icon in the browser address bar.

If your site doesn’t have a valid SSL certificate, Chrome, Firefox, and Safari will display a “Not Secure” warning before users even reach your content. For anything involving logins, contact forms, or payments, that warning is effectively a stop sign. Even for a simple blog, missing HTTPS hurts your search engine rankings — Google has used HTTPS as a ranking signal since 2014.

This article explains what SSL certificates are, the different types available, what happens when things go wrong, and how to verify your certificate is working properly. If you’re on a Host & Tech Shared Hosting plan, you likely already have access to a free Let’s Encrypt certificate — but there are still a few things worth knowing before you assume everything’s configured correctly.

Prerequisites

• Access to your hosting control panel (cPanel, Plesk, or WHM) or your Host & Tech client area
• A domain name pointed to your hosting account (DNS must be fully propagated — usually 24–48 hours after any recent changes)
• Basic understanding of what a domain name and web server are
• For wildcard or OV/EV certificates: ability to verify domain or business ownership via email or DNS record

How SSL Actually Works

When a visitor’s browser connects to your site, SSL does a quick handshake before any page content loads. The server presents its certificate, the browser verifies it was issued by a trusted Certificate Authority (CA), and both sides agree on an encryption key for that session. All data sent after that — form submissions, login credentials, payment details — is encrypted in transit.

The certificate itself contains your domain name, the name of the CA that issued it, and an expiry date. If any of those don’t check out (wrong domain, expired cert, self-signed cert not from a trusted CA), the browser throws a warning. This is why a certificate issued for example.com won’t work on shop.example.com unless it’s a wildcard cert covering *.example.com.

One thing beginners often don’t realise: SSL doesn’t make your website secure in a broad sense. It protects data in transit. A site with SSL can still have vulnerable plugins, weak passwords, or an outdated CMS. SSL is one layer of security, not a complete solution.

Types of SSL Certificates

Domain Validated (DV)

The CA confirms you control the domain — nothing more. Issued in minutes, often free via Let’s Encrypt. This is what most websites use and it’s perfectly adequate for blogs, portfolios, and small business sites. The padlock looks identical to more expensive certificates in every browser.

Organisation Validated (OV)

The CA verifies your domain and your organisation’s legal existence. Takes a few days. Shows your company name in the certificate details (not in the address bar, but users can click the padlock to see it). Worth considering for corporate sites where business legitimacy matters.

Extended Validation (EV)

The most thorough vetting — the CA confirms your legal entity, physical address, and operational status. Previously showed a green address bar with your company name, but major browsers dropped that visual treatment around 2019. EV certs are still used by financial institutions and large enterprises, but the visible difference to end users is now minimal.

Wildcard Certificates

Covers your root domain and all first-level subdomains: a cert for *.example.com works on www.example.com, mail.example.com, shop.example.com, and so on. It does not cover sub.shop.example.com — that’s two levels deep and requires a separate cert or a multi-domain (SAN) certificate.

Multi-Domain (SAN) Certificates

Covers a list of specific domains and subdomains in a single certificate using Subject Alternative Names. Useful if you manage several unrelated domains on one server.

Free vs. Paid SSL Certificates

Let’s Encrypt provides free DV certificates and is trusted by all major browsers. The certificates expire every 90 days, but on any properly configured hosting account (including all Host & Tech shared hosting plans), renewal is automatic. I’d recommend checking that auto-renewal is actually running rather than assuming it is — more on that in the troubleshooting section below.

Paid certificates from CAs like Sectigo, DigiCert, or GlobalSign make sense when you need OV/EV validation, a wildcard that Let’s Encrypt’s ACME client isn’t issuing cleanly in your environment, or when your organisation requires a commercially backed warranty (some enterprises require this for compliance reasons). For the vast majority of sites, a free Let’s Encrypt cert is the right call.

How to Verify Your SSL Certificate Is Working

1. Check the browser padlock. Load your site over https://yourdomain.com and click the padlock icon. The browser will show the certificate details, including who issued it and when it expires.
2. Run an SSL Labs scan. Go to https://www.ssllabs.com/ssltest/ and enter your domain. It’ll grade your certificate and TLS configuration, flag weak cipher suites, and flag chain issues. An A or A+ rating is what you want.
3. Check expiry from the command line. If you have SSH access to your server, run:
   Copied to clipboard

   echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

   This outputs the notBefore and notAfter dates directly from the certificate your server is serving. It’s more reliable than trusting a control panel UI.

4. Confirm HTTPS redirect is in place. HTTP requests should automatically redirect to HTTPS. In cPanel with Apache, this is typically handled via .htaccess:
   Copied to clipboard

   RewriteEngine On
   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   📝 Note: On WordPress sites, this redirect is often set in the WordPress admin under Settings → General (Site Address and WordPress Address fields should both use https://).

Common Issues and Troubleshooting

“Your connection is not private” / ERR_CERT_DATE_INVALID

The certificate has expired or the server clock is wrong. Check the expiry date with the OpenSSL command above. If the cert expired, re-issue it from cPanel (SSL/TLS → Let’s Encrypt) or trigger a manual Certbot renewal via SSH:

sudo certbot renew --force-renewal

If the cert looks valid but you’re still seeing this error, check that your server’s system clock is correct — a clock skew can cause certificate validation to fail even on a freshly issued cert.

Mixed Content Warnings (Padlock with Warning Triangle)

This happens when your page loads over HTTPS but some resources (images, scripts, stylesheets) are still referenced with http:// URLs. The page is technically on HTTPS but the browser downgrades the padlock. On WordPress, the Better Search Replace plugin is the fastest way to update hardcoded HTTP URLs in the database. For static sites, grep your source files:

grep -r "http://yourdomain.com" /path/to/webroot/

Certificate Covers Wrong Domain (NET::ERR_CERT_COMMON_NAME_INVALID)

The certificate was issued for a different domain than what the browser is requesting. Common causes: you installed a cert for example.com but the visitor is hitting www.example.com (or vice versa), or the cert doesn’t include the subdomain. Re-issue the certificate and make sure you include both example.com and www.example.com as SANs. Let’s Encrypt makes this easy — just add both domains when generating the cert.

Let’s Encrypt Auto-Renewal Failing Silently

This is annoyingly common. The renewal cron job exists but fails due to a firewall blocking port 80 (Let’s Encrypt’s HTTP-01 challenge requires port 80 to be open, even if your site runs on 443), or a stale CAA DNS record. Check the Certbot log at /var/log/letsencrypt/letsencrypt.log for the actual error. I’d recommend setting a calendar reminder to check certificate expiry 30 days out — don’t rely entirely on automation for something this critical.

SSL Works in Browser but API/App Returns Certificate Errors

Usually a missing intermediate certificate (incomplete chain). Your browser is lenient and fetches missing intermediates automatically; most HTTP clients in code (curl, Python’s requests, Node’s https module) are not. Verify your chain is complete with SSL Labs or by running:

openssl s_client -connect yourdomain.com:443 -showcerts

If you see only one certificate in the output instead of two or three, your chain is incomplete. Re-install the certificate with the full chain file from your CA.

FAQ