Type something to search...
What is an SSL/TLS certificate and how does it work?

What is an SSL/TLS certificate and how does it work?

An SSL/TLS certificate is a small digital file installed on your web server that proves your website's identity and allows browsers to set up an encrypted HTTPS connection with it. It works by binding your domain name to a public key, signed by a trusted certificate authority (CA), so that when a visitor connects, their browser can verify it's really talking to your site and then agree on encryption keys that keep the connection private and tamper-proof.

Certificates are now a basic requirement for every website, not just online stores. Browsers label plain HTTP sites as "Not secure," many modern web features only work over HTTPS, and search engines treat HTTPS as a positive signal. This article explains what certificates are, the difference between SSL and TLS, how the TLS handshake works, the types of certificates available, and how to get, install, and check one.

SSL vs. TLS: What's the Difference?

SSL (Secure Sockets Layer) was the original protocol for encrypting web traffic, developed in the 1990s. All versions of SSL are now obsolete and insecure. Its successor, TLS (Transport Layer Security), replaced it, and today's secure connections use TLS 1.2 or TLS 1.3.

The name "SSL certificate" stuck around out of habit. When someone says "SSL certificate," they almost always mean a certificate used with TLS. The certificate itself isn't tied to a protocol version; the same certificate works with TLS 1.2 and 1.3. In this article, "SSL/TLS certificate" and "TLS certificate" mean the same thing.

What's Inside a Certificate?

A certificate follows a standard format called X.509. It contains several key pieces of information:

  • Subject: The domain name (or names) the certificate covers, such as example.com and www.example.com. Modern certificates list these in the Subject Alternative Name (SAN) field.
  • Public key: The public half of a key pair. The matching private key stays secret on your server.
  • Issuer: The certificate authority that signed and issued the certificate.
  • Validity period: The "not before" and "not after" dates. Maximum lifetimes for publicly trusted certificates are being reduced in stages, from roughly 13 months toward as little as 47 days by the end of the decade, which is why automated renewal matters.
  • Digital signature: The CA's cryptographic signature proving the certificate hasn't been altered.
  • Serial number and extensions: Identifiers and details such as permitted uses.

Public and Private Keys

Certificates rely on asymmetric cryptography. You generate a key pair:

  1. The private key: Kept secret on your server. Anyone who has it can impersonate your site, so it must never be shared.
  2. The public key: Included in the certificate and shared with every visitor.

Data encrypted or signed with one key can only be verified or decrypted with the other. This lets a browser confirm that your server holds the private key matching the certificate, without that key ever leaving your server.

What Is a Certificate Authority?

A certificate authority is an organization trusted to verify that whoever requests a certificate actually controls the domain (and, for some certificate types, that the organization is real). Examples include Let's Encrypt, DigiCert, Sectigo, and GlobalSign.

Browsers and operating systems ship with a list of trusted root certificates. CAs use these roots to sign intermediate certificates, which in turn sign your site's certificate. This forms a chain of trust:

  1. Root certificate: Pre-installed and trusted by the browser or OS.
  2. Intermediate certificate: Signed by the root, used by the CA for day-to-day issuance.
  3. Leaf (server) certificate: Your site's certificate, signed by the intermediate.

When your server sends its certificate, it should also send the intermediate certificate(s). The browser follows the chain back to a trusted root. If any link is missing or invalid, the browser shows a warning.

How the TLS Handshake Works

The handshake is the short negotiation that happens before any page content is sent. Here's a simplified view of a TLS 1.3 handshake:

  1. Client Hello: The browser connects and sends the TLS versions and cipher suites it supports, a random value, and key-share information for establishing encryption keys. It also includes the domain name it wants (Server Name Indication, or SNI), so a server hosting many sites knows which certificate to present.

  2. Server Hello: The server picks a TLS version and cipher suite, sends its own key-share, and both sides can now compute shared session keys using an algorithm like elliptic-curve Diffie-Hellman.

  3. Certificate and Verification: The server sends its certificate chain and a signature proving it holds the private key. From this point, the handshake messages are already encrypted.

  4. Browser Checks: The browser verifies the chain of trust, confirms the domain matches, checks the validity dates, and checks the signature.

  5. Finished: Both sides confirm the handshake wasn't tampered with, and encrypted application data (your web page) starts flowing.

TLS 1.3 completes this in a single round trip, making it faster than TLS 1.2, and it removed older, weaker algorithms entirely.

What the Certificate Does and Doesn't Do

It's important to understand the certificate's actual role:

  • It proves identity: The browser knows it's connected to the real example.com.
  • It enables key exchange authentication: It prevents someone in the middle from substituting their own keys.
  • The session keys do the encryption: The actual page data is encrypted with fast symmetric keys negotiated during the handshake.

A certificate does not make your website "safe" in a broader sense. A site with a valid certificate can still be hacked or serve malware. The padlock only means the connection is encrypted and the domain is verified.

Types of SSL/TLS Certificates

Certificates differ in how thoroughly the CA verifies the requester and in how many domains they cover.

By Validation Level

  • Domain Validated (DV): The CA only confirms you control the domain, usually via a DNS record or a file on your server. Issued in minutes, often free. Suitable for the vast majority of websites.
  • Organization Validated (OV): The CA also verifies that the organization exists. Details appear in the certificate but browsers display it the same way as DV.
  • Extended Validation (EV): The most thorough checks. Browsers used to show a green bar with the company name, but modern browsers no longer display EV differently in the address bar, so its visible benefit has largely disappeared.

All three provide the same strength of encryption.

By Domain Coverage

  • Single-domain: Covers one hostname, often plus its www variant.
  • Wildcard: Covers a domain and all its first-level subdomains, such as *.example.com. Requires DNS validation with Let's Encrypt.
  • Multi-domain (SAN): Covers a list of different hostnames in one certificate.

How to Get an SSL/TLS Certificate

You have three common routes.

  1. Through your host: Most hosts, including managed WordPress hosts, issue free Let's Encrypt certificates automatically. Look for an SSL or TLS section in your hosting control panel, such as cPanel > SSL/TLS Status, and enable it.

  2. Through a CDN: Services like Cloudflare issue a certificate for the connection between visitors and the CDN. Make sure the connection from the CDN to your server is also encrypted (Cloudflare's "Full (strict)" mode).

  3. Yourself, on a VPS: Use Certbot or a similar ACME client to request and renew Let's Encrypt certificates.

Installing a Certificate with Certbot

On Ubuntu or Debian with Nginx, the recommended installation method for Certbot is via snap:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot --nginx -d example.com -d www.example.com

For Apache, replace --nginx with --apache. Certbot requests the certificate, updates your server configuration, and sets up automatic renewal. You can test renewal with:

sudo certbot renew --dry-run

A Sensible Nginx TLS Configuration

If you manage Nginx yourself, a modern configuration looks like this:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /var/www/example.com;
    index index.php index.html;
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Note that fullchain.pem includes the intermediate certificate, which avoids chain errors. The http2 on; directive requires Nginx 1.25.1 or newer; on older versions, add http2 to the listen line instead. Mozilla's SSL Configuration Generator is a good reference for up-to-date settings.

How to Check Your Certificate

You can inspect a certificate in your browser by clicking the icon to the left of the address bar and viewing the connection or certificate details. From the command line, OpenSSL shows the issuer, subject, and validity dates:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Online tools like SSL Labs' SSL Server Test give a detailed grade covering protocol support, chain issues, and configuration.

Common Certificate Errors

  • Expired certificate: Renewal failed or wasn't set up. Automate renewals and monitor expiry dates.
  • Name mismatch: The certificate doesn't cover the hostname being visited, such as a missing www variant.
  • Incomplete chain: The server isn't sending the intermediate certificate. Use the full chain file.
  • Self-signed certificate: Not issued by a trusted CA. Fine for local development, not for public sites.
  • Mixed content: The page loads over HTTPS but includes images or scripts over HTTP. Update those URLs to HTTPS.

HTTPS and WordPress

Once your certificate is installed, make sure WordPress uses HTTPS URLs. In Settings > General, both the WordPress Address and Site Address should begin with https://. The full process of migrating an existing site from HTTP to HTTPS, including database URL updates and redirects, is covered in a separate article on this blog.


FAQ: SSL/TLS Certificates

Not technically. SSL is the older, now-insecure protocol, and TLS is its modern replacement. The term SSL certificate is still widely used, but those certificates are used with TLS today.

Yes, in terms of encryption. A free Let's Encrypt DV certificate provides the same encryption strength as a paid one. Paid certificates may offer organization validation, warranties, or support, but they don't encrypt any better.

No. It means the connection is encrypted and the domain is verified. It doesn't protect against hacked plugins, malware, or weak passwords, and phishing sites often have valid certificates too.

Let's Encrypt certificates are typically valid for 90 days and renew automatically, and Let's Encrypt plans to shorten that further. Commercial certificates last longer, but industry-wide maximum lifetimes are being cut in stages over the next few years, so automated renewal is increasingly important.

Visitors see a full-page browser warning saying the connection isn't private, and most will leave. Automated renewal and expiry monitoring prevent this.

Only if you run many subdomains and want one certificate to cover them all. For most sites with just a main domain and www, a standard certificate is enough.

Yes. HTTPS protects the integrity of your pages, prevents tampering by networks, avoids browser warnings, and is required for many modern browser features. Every public website should use it.


Conclusion

An SSL/TLS certificate binds your domain to a public key and is signed by a trusted certificate authority. During the TLS handshake, the browser uses it to verify your site's identity, then negotiates session keys that encrypt everything exchanged afterward. It's the foundation of HTTPS and the padlock in the address bar.

For most sites, a free, automatically renewing domain-validated certificate from Let's Encrypt or your host is all you need. Make sure renewal is automated, serve the full certificate chain, support TLS 1.2 and 1.3, redirect HTTP to HTTPS, and check your setup with a tool like SSL Labs. Remember that the certificate secures the connection, not the whole site, so keep building the other layers of your security too.

Tags :
Share :

Related Posts

What are the best WordPress security plugins?

What are the best WordPress security plugins?

The best WordPress security plugins for most sites are Wordfence, Sucuri Security, Solid Security, MalCare, All-In-One Security (AIOS), Patchstack, a

Dive Deeper
What are the most common website security threats?

What are the most common website security threats?

The most common website security threats are vulnerable or outdated software, weak and stolen passwords, malware infections, injection attacks like S

Dive Deeper
How does GDPR affect website security?

How does GDPR affect website security?

GDPR affects website security by turning it from a good habit into a legal obligation. If your website collects personal data from people in the EU (

Dive Deeper