Installing an SSL certificate sounds intimidating right up until you’ve done it once. In practice it’s three steps — get a certificate, install it, and confirm HTTPS works with no warnings — and modern hosting tools automate most of the hard part.

This guide covers getting a free certificate via Let’s Encrypt, installing through cPanel’s AutoSSL or a manual upload, through Plesk, and entirely by hand with OpenSSL. It also covers what people skip and regret later: verifying the install, forcing HTTPS, fixing mixed-content warnings, and automating renewal.

1. What an SSL Certificate Actually Does

An SSL/TLS certificate does two things: it encrypts the data traveling between a visitor’s browser and your server, and it proves your server is who it claims to be. Technically it’s a TLS certificate now — “SSL” is the outdated protocol name, but the industry still uses both interchangeably.

The browser performs a TLS handshake: the server presents its certificate, the browser checks that a trusted Certificate Authority (CA) signed it and it matches the domain, and both sides negotiate an encryption key for the session. If any check fails — expired, mismatched, untrusted issuer — the browser blocks the connection.

Without a valid certificate, every major browser flags the page “Not Secure” and warns before login or payment forms load over plain HTTP. HTTPS is also a minor Google ranking factor, and while the HTTP/2 spec itself doesn’t mandate encryption, no major browser supports it unencrypted — and HTTP/3, built on QUIC, requires TLS 1.3 by design. See our guide on how hosting affects SEO.

2. Certificate Types: DV, OV, EV & Free vs. Paid

All certificates encrypt identically — the differences are in how much vetting the CA does before issuing one, and what’s bundled alongside it.

• Domain Validated (DV) — confirms only that you control the domain. Issued in minutes, fully automatable. What Let’s Encrypt, ZeroSSL, and AutoSSL all issue.
• Organization Validated (OV) — additionally verifies your business is a real, registered entity. Takes a few days; no different browser chrome, just more detail in the certificate itself.
• Extended Validation (EV) — the most rigorous vetting, historically shown with a green address bar and company name. Chrome dropped that UI in version 77 and Firefox in version 70, both in 2019. In 2026 an EV certificate looks identical to a DV one in every browser’s address bar.

Free certificates lack an OV/EV option and any vendor warranty, and renew every 90 days instead of annually — but for most sites that doesn’t matter, since automation handles renewal. The gap is narrowing anyway: a 2025 CA/Browser Forum ballot caps all publicly trusted certificates, paid included, at 200 days as of March 2026, shrinking to 100 in 2027 and 47 by 2029. Short-lived, auto-renewed certificates are becoming the default regardless.

3. Getting a Free Certificate via Let’s Encrypt

Let’s Encrypt is a nonprofit CA that issues free DV certificates using the ACME protocol — an automated system where a client on your server proves domain ownership and requests the certificate, no human form-filling involved. Most hosts already wire this into their control panel (see cPanel and Plesk below). If you manage your own server, here’s how it works.

The officially recommended ACME client is Certbot, maintained by the EFF. It supports two validation methods: HTTP-01, where a temporary file confirms domain control over HTTP, and DNS-01, a temporary TXT record — required for wildcard certificates (*.example.com), which can’t validate over HTTP.

# Certbot's own instructions now recommend snap over your distro's apt package
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

# Requests a cert and edits the Apache config for you
sudo certbot --apache -d example.com -d www.example.com

# Or, to get the cert files without touching your config:
sudo certbot certonly --webroot -w /var/www/example.com -d example.com

Certbot writes the certificate, private key, and intermediate chain to /etc/letsencrypt/live/example.com/, ready to reference from your web server config. On Nginx, swap the flag: certbot --nginx (or certbot certonly --nginx to skip auto-editing your config).

4. Installing via cPanel

Option A: AutoSSL (Free, Automatic)

AutoSSL is cPanel’s built-in automation for issuing and renewing free DV certificates. It used to let hosts choose between Let’s Encrypt and Sectigo as the issuing CA, but cPanel deprecated the Sectigo AutoSSL provider and removed it outright in WHM version 120 — Let’s Encrypt is now effectively the only built-in option. It’s already running for every domain on most shared hosting accounts.

1. Check your certificate status Look for SSL/TLS Status under Security. It lists each domain and its current certificate type and expiration.
2. Run AutoSSL if a domain isn’t covered Select the domain and use Run AutoSSL to validate it and issue a certificate — no CSR, no copy-pasting.
3. Ask your host if it’s missing AutoSSL is configured at the server (WHM) level. If it’s disabled on your plan, ask your host to enable it — it’s standard on nearly every modern shared hosting plan.

Option B: Installing a Purchased Certificate

For an OV/EV certificate bought elsewhere, install it manually.

1. Generate a CSR Under Security → SSL/TLS → Certificate Signing Requests, generate one for your domain — your CA uses this to issue the certificate.
2. Validate with your CA Submit the CSR and complete domain (and, for OV/EV, organization) validation. The CA emails back the certificate plus an intermediate/CA bundle.
3. Install under SSL/TLS → Manage SSL Sites Paste the Certificate (CRT), Private Key, and Certificate Authority Bundle into their fields. Don’t skip the CA bundle — it’s the intermediate chain that makes the certificate trusted everywhere, not just on some devices.
4. Save and verify Visit your site over HTTPS to confirm the padlock, then run the checks in section 7.

5. Installing via Plesk

Plesk’s certificate management lives under Websites & Domains for the domain in question, in a tool typically labeled SSL/TLS Certificates. Exactly how free certificates get issued has shifted between Plesk versions — older installs use a dedicated “Let’s Encrypt” extension, while current Plesk has phased that out in favor of the newer “SSL It!” extension, which also handles renewals, HSTS, and paid-CA certificates from one place. If you don’t see Let’s Encrypt directly, check your Extensions catalog for whichever SSL issuance extension your version ships with.

1. Open the domain’s SSL/TLS Certificates tool From Websites & Domains, select your domain and open its SSL/TLS Certificates page.
2. Issue a free certificate Use the Let’s Encrypt (or equivalent) option, entering an email for renewal notices and choosing which names to secure — usually the bare domain, its www variant, and webmail.yourdomain.com if applicable.
3. Or upload a purchased certificate Use the upload/add option on the same page and supply the certificate, private key, and CA/intermediate files your provider issued.
4. Assign the certificate to the domain Under Hosting Settings, enable SSL/TLS support and select the certificate from the dropdown. Skip this and the certificate exists but isn’t actually serving traffic.

6. Manual Installation: CSR & OpenSSL

Running your own server without cPanel or Plesk — a bare VPS with Apache or Nginx — means generating the key and CSR yourself with OpenSSL, getting it signed, and dropping the resulting files into your web server config.

1. Generate a private key and CSR The command below creates a 2048-bit RSA key and a Certificate Signing Request — you’ll be prompted for domain and organization details interactively.
2. Submit the CSR to a CA Paste it into your CA’s order form (or use Certbot for free Let’s Encrypt certificates, which skips manual CSR generation entirely) and complete their validation steps.
3. Download the certificate and chain The CA returns your signed certificate plus intermediate certificates. Keep the chain — it’s required for devices to trust your certificate.
4. Reference the files in your server config Add the certificate, key, and chain paths to your Apache vhost or Nginx server block, then reload the web server.

# Creates example.com.key (keep this private) and example.com.csr (send this to the CA)
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

<VirtualHost *:443>
  ServerName example.com
  DocumentRoot /var/www/example.com

  SSLEngine on
  SSLCertificateFile      /etc/ssl/certs/example.com.crt
  SSLCertificateKeyFile   /etc/ssl/private/example.com.key
  SSLCertificateChainFile /etc/ssl/certs/example.com-chain.crt
</VirtualHost>

server {
  listen 443 ssl;
  server_name example.com;

  # fullchain.pem = your certificate + the intermediate chain, in one file
  ssl_certificate     /etc/ssl/certs/example.com-fullchain.pem;
  ssl_certificate_key /etc/ssl/private/example.com.key;
}

Apache’s SSLCertificateChainFile keeps the intermediate chain in a separate file (or append it to SSLCertificateFile on Apache 2.4.8+); Nginx instead expects one “fullchain” file with your certificate followed by the intermediates concatenated together.

7. Verifying Your Installation Worked

Never assume an install worked just because the site loads with no obvious error — some misconfigurations only surface on certain browsers or devices.

• Run the SSL Labs test — ssllabs.com/ssltest flags chain issues, weak protocols, and expiration problems, and grades your setup from A+ to F.
• Check the padlock in your browser — view the certificate and confirm the domain, issuer, and expiration date.
• Query the server directly with OpenSSL — useful for scripting or a machine with no browser.

# View the full handshake and certificate chain
openssl s_client -connect example.com:443 -servername example.com

# Just the issuer and expiration dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -issuer -dates

8. Forcing HTTPS Site-Wide

Installing a certificate doesn’t automatically redirect HTTP traffic to HTTPS — visitors and old links can still hit the plain HTTP version unless you force it. On Apache/LiteSpeed hosting, that’s a rewrite rule in your .htaccess file:

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

Place this above any WordPress rewrite block, back up your existing .htaccess first, and test the homepage plus an inner page immediately after saving.

9. Fixing Mixed-Content Errors

Once HTTPS is forced, the padlock can still turn into a “not fully secure” warning: mixed content, where some resource — an image, script, or stylesheet — is still hardcoded to http://. Open DevTools (F12), reload, and the console lists every flagged URL.

On WordPress, this is almost always leftover http:// URLs baked into post content from before the migration. Fix it at the database level: Better Search Replace lets you dry-run a replace from the admin with no command line, while WP-CLI is faster with shell access.

# Always dry-run first to preview what would change
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Then run it for real once the preview looks right
wp search-replace 'http://example.com' 'https://example.com' --all-tables

A security plugin such as Really Simple Security can also rewrite HTTP resource URLs on the fly, which is a faster band-aid but doesn’t clean up the database the way a search-replace does.

10. Auto-Renewal

Letting a certificate lapse is one of the most common, avoidable causes of downtime, so know how renewal works for your path.

• Let’s Encrypt via Certbot — installing it also installs a systemd timer (or cron job) running certbot renew automatically, typically twice daily, renewing anything within 30 days of expiration. Test safely with certbot renew --dry-run.
• cPanel AutoSSL — renews automatically in the background; keep it enabled with email alerts on.
• Plesk’s SSL issuance extension — likewise renews automatically once configured.

Since the 2026 validity cap now limits even purchased certificates to 200 days, manual renewal reminders are becoming impractical industry-wide — automation is close to mandatory.

11. Common Mistakes to Avoid

Mistake 1: Skipping the Intermediate/Chain Certificate

The single most common SSL ticket. Your browser can look fine — it already trusts the missing intermediate from another site — while other visitors see “certificate not trusted.” Always install the full chain.

Mistake 2: Letting a Certificate Expire

An expired certificate takes the whole site down behind a full-page warning. Confirm auto-renewal is actually working (section 10) rather than relying on a manual reminder.

Mistake 3: Certificate/Private Key Mismatch

Installing a certificate against a private key from a different CSR attempt fails outright or produces handshake errors. Keep each key paired with its own CSR’s certificate.

Mistake 4: Single-Domain vs. SAN vs. Wildcard Confusion

A single-domain certificate for example.com doesn’t cover www.example.com or any subdomain — each needs a SAN entry, or a wildcard (*.example.com), which covers subdomains but not the bare root unless it’s added too.

Mistake 5: Forgetting to Force HTTPS Afterward

Installing the certificate makes HTTPS available, not the default. Without the redirect rule (section 8), traffic and SEO signals split across both versions indefinitely.

12. Troubleshooting a Broken Certificate

If your site is showing a certificate warning right now, work through this in order rather than guessing.

1. Read the exact browser error “Expired,” “not trusted,” and “name mismatch” point to different problems — click “Advanced” or “Certificate details” for specifics.
2. Check the expiration date Run the OpenSSL date-check from section 7. If it’s expired, reissue and reinstall — renewal automation likely failed silently.
3. Confirm the chain is complete Run the SSL Labs test from a device other than your own — it flags “Chain issues” even when your local browser shows the site as secure.
4. Verify the certificate matches the domain A “name mismatch” means the certificate lacks a SAN for the hostname you’re visiting — commonly a missing www variant or subdomain.
5. Confirm the web server actually reloaded On a manually managed server, a certificate replaced on disk doesn’t take effect until you run systemctl reload apache2 (or nginx).
6. Rule out browser/CDN caching Test in a fresh incognito window; if you use Cloudflare or similar, check its own edge certificate and SSL mode, which can mask or conflict with your origin certificate.

13. Frequently Asked Questions