SSL/TLS Certificates Explained

By Kokil Thapa | Last reviewed: September 2026

Your browser shows a padlock, but the site still fails on some devices. That gap is why SSL/TLS Certificates Explained matters for every engineer who ships production web apps. Transport Layer Security encrypts HTTP traffic and proves the server identity to visitors. On real client projects—from law-firm portals to Laravel booking systems—I treat HTTPS as infrastructure, not a checkbox. This guide walks through how certificates work, which type to pick, and how to install and renew them on Ubuntu with Apache or Nginx.

What is the difference between SSL and TLS certificates?

SSL (Secure Sockets Layer) is the older protocol family. TLS (Transport Layer Security) replaced it. People still say "SSL certificate" because hosting panels and vendors never updated the label. The file you install is an X.509 certificate. It binds a domain name to a public key. The private key stays on your server.

Modern servers should disable SSL 3.0 and early TLS versions. TLS 1.2 remains widely deployed. TLS 1.3 is the current best practice for new configs. See our TLS 1.3 vs 1.2 Nginx guide for cipher tuning. Mozilla publishes a maintained baseline at wiki.mozilla.org/Security/Server_Side_TLS.

HTTPS uses TCP port 443. HTTP on port 80 should redirect to HTTPS. Google treats HTTPS as a ranking signal. Browsers mark plain HTTP as "Not secure." For sites handling logins, payments, or document uploads, encryption is non-negotiable.

Do not confuse transport certificates with Nepal digital signature certificates used for legal document signing. They solve different problems. Transport certs protect data in flight. Digital signatures prove document authenticity under local law.

How does the SSL/TLS handshake work?

The handshake runs before any HTTP request body is sent. It negotiates protocol version, selects ciphers, authenticates the server, and derives session keys. TLS 1.3 completes in one round trip. TLS 1.2 typically needs two.

Step-by-step handshake sequence

1. The client sends a ClientHello with supported TLS versions and cipher suites.
2. The server replies with ServerHello, its certificate chain, and (in TLS 1.2) key exchange parameters.
3. The client validates the certificate against its trust store and checks hostname match via Subject Alternative Names.
4. Both sides derive symmetric keys and switch to encrypted application data.

A broken chain stops the handshake cold. The leaf certificate must chain to an intermediate, then to a root CA in the browser trust store. Many production failures trace back to missing intermediate files, not the leaf cert itself.

Certificate Transparency logs help detect mis-issued certs. Major CAs publish to CT logs as a requirement. You can inspect entries at crt.sh, a public CT search tool maintained by Sectigo.

On Laravel apps behind Apache, I verify the handshake with OpenSSL before touching application code. A TLS problem looks like an app bug until you isolate the layer.

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

The command prints validity dates, subject, and issuer. Run it after every cert change. Compare the output to what Certbot or your CA dashboard shows.

What types of SSL/TLS certificates should you choose?

Validation level and coverage scope are the two decisions that matter. Price follows from those choices. Most business sites need Domain Validation on every hostname they serve.

For a typical Nepal business site—a legal portal, florist shop, or booking app—DV from Let's Encrypt covers the requirement fully. OV adds paperwork, not stronger encryption. The cipher suite and TLS version determine security strength, not the validation badge color.

Wildcard vs separate certificates

A wildcard cert simplifies ops for many subdomains. It requires DNS-01 validation because HTTP-01 cannot prove control of arbitrary subdomains. Separate certs per host are fine when you use Certbot's Apache or Nginx plugin on a single VPS.

On shared EC2 infrastructure where I run Deployer 7 releases, each vhost gets its own Let's Encrypt cert. Renewal stays isolated. One bad DNS change does not break every site on the box.

Use our password generator for strong admin credentials. Protect the private key file with restrictive permissions. Never commit keys to Git.

How do you install and renew SSL/TLS certificates on a Linux server?

Let's Encrypt via Certbot is the standard path on Ubuntu 22/24 with Apache or Nginx. Certs expire every 90 days. Auto-renewal via systemd timer or cron is mandatory.

Install Certbot on Ubuntu

sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

For Apache, swap the plugin package to python3-certbot-apache and use --apache. Certbot writes the vhost SSL directives and obtains the cert in one step. Full walkthrough: Let's Encrypt and Certbot setup guide.

Manual certificate paths

Certbot stores files under /etc/letsencrypt/live/example.com/:

• fullchain.pem — leaf plus intermediate (use this as SSLCertificateFile)
• privkey.pem — private key (mode 600, owned by root or the web server user)
• cert.pem — leaf only (rarely used alone)
• chain.pem — intermediate only

Nginx SSL block example:

server {
    listen 443 ssl http2;
    server_name 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;

    root /var/www/example/public;
    index index.php;
}

Apache equivalent uses SSLEngine on with the same file paths inside a <VirtualHost *:443> block. Reload the web server after changes. See install SSL on Ubuntu for PHP-FPM pairing notes.

Renewal and automation

sudo certbot renew --dry-run
sudo systemctl list-timers | grep certbot

The dry-run simulates renewal without replacing live certs. Fix any failure before the 90-day window closes. I've seen cron jobs point to stale release paths after Deployer symlink swaps. Always use absolute paths in cron.

For Kubernetes workloads, cert-manager automates TLS with ACME issuers. Load balancers may terminate TLS upstream—see HAProxy TLS configuration when SSL ends before your app servers.

Need hands-on help? Our Linux system administration service covers Certbot, firewall rules, and PHP-FPM reloads after cert rotation. Domain and hosting setup includes initial HTTPS configuration for new sites.

How do you troubleshoot common SSL/TLS certificate problems?

Most errors fall into five buckets. Work through them in order before blaming application code.

Hostname mismatch (ERR_CERT_COMMON_NAME_INVALID)

The certificate SAN list must include the exact hostname the user typed. A cert for example.com alone will fail on www.example.com. Re-issue with all variants or redirect www to apex consistently.

Expired certificate (NET::ERR_CERT_DATE_INVALID)

Check dates with OpenSSL or your browser dev tools. Renewal failed silently when cron used the wrong user or port 80 was blocked during HTTP-01 validation. Open port 80 for challenges even if all traffic redirects to HTTPS.

Incomplete chain

Serve fullchain.pem, not cert.pem. Test at SSL Labs or with:

openssl s_client -connect example.com:443 -showcerts < /dev/null

Count the certificates in the output. You should see at least two: leaf and intermediate.

Mixed content warnings

HTTPS pages that load HTTP scripts, images, or API calls trigger browser warnings. Search your Blade templates and CSS for hard-coded http:// URLs. Use protocol-relative paths or force HTTPS in Laravel's AppServiceProvider with URL::forceScheme('https') behind a trusted proxy.

Redirect loops

Cloudflare or a load balancer terminates SSL and forwards HTTP to origin. If origin also redirects to HTTPS, you get an infinite loop. Set the correct X-Forwarded-Proto header and configure Laravel's TrustProxies middleware.

After fixing TLS, run a quick speed optimization pass. HTTP/2 and TLS 1.3 improve load times when configured correctly. Our testing and optimization service includes HTTPS audits as part of pre-launch checks.

On legal-tech portals like Notary Nepal and Mijar Law Associates, clients upload sensitive documents. A valid cert builds trust before they reach the login form. Technical SEO also benefits—Google crawls HTTPS URLs preferentially when duplicates exist.

Migrating from HTTP to HTTPS? Update canonical tags, sitemap URLs, and internal links in one pass. Our website migration service covers redirect maps and Search Console property updates. For ongoing renewals and server patches, support and maintenance keeps certs current.

Automate provisioning with Ansible playbooks for PHP servers if you manage multiple VPS instances. Store API tokens for DNS-01 challenges in encrypted vault variables, not plain text inventory files.

Key Takeaways

• SSL/TLS certificates bind your domain to a public key; TLS 1.3 with Let's Encrypt DV certs is enough for most production sites.
• Always serve fullchain.pem on the server and keep the private key at mode 600 with auto-renewal tested via certbot renew --dry-run.
• Validate hostname coverage in SAN fields for every subdomain you expose, including www and API hosts.
• Diagnose handshake failures with openssl s_client before debugging Laravel, WordPress, or application-layer code.
• Fix mixed content and proxy header issues after installing the cert—HTTPS is a stack-wide change, not just a vhost edit.
• Schedule renewal monitoring; expired certs take down payment flows, login pages, and API clients without warning.

People Also Ask

Are SSL and TLS certificates the same thing?

Colloquially yes. Technically TLS replaced SSL, but the certificate format (X.509) is identical. Vendors and control panels still label them "SSL certificates." Configure your server for TLS 1.2 and TLS 1.3, not legacy SSL protocols.

Can I get a free SSL/TLS certificate for production?

Yes. Let's Encrypt issues free DV certificates trusted by all major browsers. Certbot automates issuance and renewal on Linux. Commercial CAs add OV/EV validation and warranty policies, not stronger encryption.

How long do SSL/TLS certificates last?

Let's Encrypt certs expire after 90 days, which encourages automated renewal. Commercial CAs typically offer one- or two-year terms. Shorter lifetimes reduce risk from compromised keys and mis-issued certificates.

Do I need SSL/TLS for an API that only serves mobile apps?

Yes. Mobile apps still connect over the public internet. Without TLS, tokens and payloads are visible to anyone on the same network. Use HTTPS for all API endpoints and pin certificates only if you understand the operational cost of rotation.

Put HTTPS on solid ground

Once you have SSL/TLS certificates explained end to end—chain of trust, validation types, installation, renewal, and troubleshooting—you can treat HTTPS as reliable infrastructure rather than a launch-day surprise. Start with Let's Encrypt on your staging server, verify the chain with OpenSSL, then roll the same pattern to production. If you want help wiring Certbot into your Deployer pipeline or fixing a broken chain on a live law-firm portal, contact us for a focused audit. For broader context on building secure sites from scratch, see our web development service and related posts on the blog.