How to Install an SSL Certificate on a Domain

An SSL certificate (Secure Sockets Layer / TLS) is a cryptographic credential issued by a trusted Certificate Authority (CA) that authenticates your server's identity and establishes an encrypted channel between the server and the client's browser. When installed correctly, it upgrades your site from http:// to https://, activates the browser padlock, and prevents man-in-the-middle interception of transmitted data.

For SEO, Google has treated HTTPS as a confirmed ranking signal since 2014. For users, a missing or misconfigured certificate triggers browser security warnings that kill conversion rates. Whether you manage a single landing page or a multi-domain infrastructure, getting SSL right — and keeping it right — is non-negotiable.

Prerequisites Before You Begin

Before touching a single configuration file, confirm you have the following in place:

• A registered domain name pointed to your server's IP address with DNS fully propagated. You can register or transfer a domain through Domain Registration.
• An SSL certificate bundle from a CA. This typically includes:

certificate.crt — your primary signed certificate
private.key — the private key generated alongside your CSR
ca_bundle.crt — the intermediate CA chain (sometimes called a chain file)
Server or control panel access — either cPanel/Plesk credentials or SSH root/sudo access to the server.
Web server software — Apache or Nginx, running and configured for your domain.
Open port 443 — verify your firewall allows inbound TCP on port 443 before installing anything.

If you are running a VPS Hosting environment, you will have full root access and can use any of the three methods below. Shared hosting users are typically limited to the cPanel method.
Choosing the Right SSL Certificate Type
Not all certificates are equivalent. Selecting the wrong type wastes money or leaves gaps in coverage.



Certificate Type
Validation Level
Issuance Time
Browser Padlock
Best For








—
—
—
—
—








DV (Domain Validated)
Domain control only
Minutes
Yes
Blogs, dev environments, small sites








OV (Organization Validated)
Domain + org identity
1–3 days
Yes
Business websites, SaaS platforms








EV (Extended Validation)
Full legal entity check
3–7 days
Yes (org name in some browsers)
E-commerce, banking, high-trust portals








Wildcard (`*.domain.com`)
DV or OV
Minutes–days
Yes
Multi-subdomain deployments








Multi-Domain (SAN)
DV, OV, or EV
Varies
Yes
Multiple distinct domains on one cert








Let's Encrypt (free DV)
Domain control only
Seconds
Yes
Any publicly accessible domain





For production e-commerce or any site handling payment card data, OV or EV certificates from a commercial CA are strongly recommended. Let's Encrypt DV certificates are fully trusted and excellent for most use cases, but they do not include organizational identity verification.
You can purchase commercial certificates directly through SSL Certificates if you need OV, EV, or Wildcard coverage with dedicated support.
Method 1: Installing an SSL Certificate via cPanel
cPanel's graphical interface is the fastest path for users on managed or Shared Web Hosting plans. If you prefer a cPanel-managed VPS environment, a VPS with cPanel gives you the same interface with full server control.
Step 1: Log In to cPanel
Navigate to your cPanel login URL:
https://yourdomain.com:2083
Authenticate with your hosting credentials.
Step 2: Navigate to SSL/TLS Manager
In the Security section of the cPanel dashboard, click SSL/TLS. Then select Manage SSL Sites under the "Install and Manage SSL for your site (HTTPS)" heading.
Step 3: Select the Target Domain
Use the Domain dropdown to select the domain you want to secure. If the domain does not appear, confirm it is added as an addon or primary domain in cPanel.
Step 4: Paste Certificate Components
Open each certificate file in a plain-text editor (not Word) and paste the contents into the corresponding fields:

Certificate (CRT): Contents of certificate.crt

Step 5: Install and Verify

Click Install Certificate. cPanel validates the key-certificate pair before committing. If there is a mismatch between the private key and the certificate's public key, cPanel will reject the installation with an explicit error — do not ignore it.

After installation, visit https://yourdomain.com and confirm the padlock appears. Also test https://www.yourdomain.com if the www subdomain is in use.

Common cPanel pitfall: AutoSSL (cPanel's built-in Let's Encrypt integration) may overwrite a manually installed certificate at its next renewal cycle. If you installed a commercial certificate, disable AutoSSL for that domain under cPanel > SSL/TLS Status to prevent unintended replacement.

Method 2: Automated Installation with Let's Encrypt and Certbot

Certbot is the reference ACME client for Let's Encrypt. It handles CSR generation, domain validation, certificate retrieval, web server configuration, and renewal — all automatically. This is the correct approach for any Linux server you manage directly.

Step 1: Connect to Your Server via SSH

ssh username@your-server-ip

Step 2: Install Certbot

Debian / Ubuntu (Apache):

sudo apt update && sudo apt install -y certbot python3-certbot-apache

Debian / Ubuntu (Nginx):

sudo apt update && sudo apt install -y certbot python3-certbot-nginx

RHEL / AlmaLinux / Rocky Linux (Apache):

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-apache

RHEL / AlmaLinux / Rocky Linux (Nginx):

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-nginx

Step 3: Obtain and Install the Certificate

For Apache:

sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

For Nginx:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot performs an HTTP-01 challenge by default: it places a temporary file in your web root and asks Let's Encrypt's servers to fetch it over port 80. This means port 80 must be open and your DNS must resolve correctly before running the command.

When prompted, select the option to redirect all HTTP traffic to HTTPS. This writes a permanent 301 redirect into your server configuration, which is the correct behavior for SEO and security.

Step 4: Verify Automatic Renewal

Let's Encrypt certificates expire after 90 days. Certbot installs a systemd timer (or cron job on older systems) that attempts renewal twice daily when the certificate is within 30 days of expiry. Test the renewal logic without actually renewing:

sudo certbot renew --dry-run

A successful dry run confirms the renewal pipeline is intact. Check the timer status with:

systemctl status certbot.timer

Edge case — DNS-01 challenge for wildcard certificates: The HTTP-01 challenge cannot validate wildcard domains (*.yourdomain.com). For wildcards, use the DNS-01 challenge, which requires you to create a _acme-challenge TXT record in your DNS zone:

sudo certbot certonly --manual --preferred-challenges dns -d "*.yourdomain.com" -d yourdomain.com

Follow the prompts to add the TXT record, wait for DNS propagation, then press Enter to complete validation.

Method 3: Manual SSL Installation via SSH (Apache and Nginx)

Manual installation gives you precise control over certificate placement, cipher suites, and virtual host configuration. This is the preferred approach for production servers where you need to enforce specific TLS policies.

Step 1: Upload Certificate Files to the Server

Use scp to transfer files from your local machine:

scp certificate.crt private.key ca_bundle.crt username@your-server-ip:/tmp/

Then move them to a secure, non-web-accessible directory:

sudo mkdir -p /etc/ssl/yourdomain
sudo mv /tmp/certificate.crt /etc/ssl/yourdomain/
sudo mv /tmp/private.key /etc/ssl/yourdomain/
sudo mv /tmp/ca_bundle.crt /etc/ssl/yourdomain/
sudo chmod 600 /etc/ssl/yourdomain/private.key
sudo chmod 644 /etc/ssl/yourdomain/certificate.crt /etc/ssl/yourdomain/ca_bundle.crt

Critical security note: The private key must never be world-readable. The chmod 600 permission restricts it to the root user only. On systems where Apache or Nginx runs as a non-root user (e.g., www-data), the service still reads the key at startup while running as root before dropping privileges — so 600 owned by root is correct.

Step 2a: Configure Apache

Edit the virtual host configuration for your domain:

sudo nano /etc/apache2/sites-available/yourdomain.com.conf

Add or modify the SSL virtual host block:

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    Redirect permanent / https://yourdomain.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/yourdomain/certificate.crt
    SSLCertificateKeyFile   /etc/ssl/yourdomain/private.key
    SSLCertificateChainFile /etc/ssl/yourdomain/ca_bundle.crt

    # Modern TLS hardening
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    DocumentRoot /var/www/yourdomain
</VirtualHost>

Enable the SSL module and site, then restart Apache:

sudo a2enmod ssl headers
sudo a2ensite yourdomain.com.conf
sudo apache2ctl configtest
sudo systemctl restart apache2

Always run apache2ctl configtest before restarting. A syntax error in the config file will take the entire web server down.

Step 2b: Configure Nginx

Edit your domain's server block:

sudo nano /etc/nginx/sites-available/yourdomain.com

Add the following configuration:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate      /etc/ssl/yourdomain/certificate.crt;
    ssl_certificate_key  /etc/ssl/yourdomain/private.key;
    ssl_trusted_certificate /etc/ssl/yourdomain/ca_bundle.crt;

    # Modern TLS hardening
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  1d;
    ssl_session_tickets  off;

    # OCSP Stapling
    ssl_stapling         on;
    ssl_stapling_verify  on;
    resolver             8.8.8.8 8.8.4.4 valid=300s;

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

    root /var/www/yourdomain;
    index index.html index.php;
}

Enable the site and test:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

OCSP Stapling explained: Without stapling, the browser must contact the CA's OCSP responder during every TLS handshake to check if the certificate has been revoked. This adds latency and leaks browsing data to the CA. With ssl_stapling on, Nginx caches the OCSP response and serves it directly to the client, eliminating the round-trip.

TLS Hardening: What the Original Configuration Misses

A certificate installed with default settings is secure, but not hardened. The following table summarizes the additional directives that separate a passing SSL Labs grade from an A+:

Verifying and Testing SSL Installation

Installation is not complete until you have verified the result from an external perspective.

Browser Verification

Visit https://yourdomain.com. The padlock icon confirms a valid, trusted certificate. Click the padlock and inspect the certificate details: verify the Common Name or Subject Alternative Name matches your domain, and check the expiry date.

SSL Labs Server Test

Navigate to SSL Labs and enter your domain. The report grades your TLS configuration from F to A+ and flags specific issues: weak cipher suites, missing chain certificates, HSTS absence, and protocol support. An A+ rating requires HSTS with a long max-age and no support for TLS 1.0 or 1.1.

Command-Line Verification with OpenSSL

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

This outputs the full certificate chain, the negotiated cipher suite, and the TLS version. Look for Verify return code: 0 (ok) at the end of the output. Any non-zero return code indicates a chain or trust problem.

To check the certificate expiry date directly:

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

Checking for Mixed Content

After enabling HTTPS, mixed content is the most common residual problem. It occurs when an HTTPS page loads resources (images, scripts, stylesheets, iframes) over HTTP. Mixed content blocks active resources (scripts, iframes) entirely in modern browsers and generates console warnings for passive resources (images).

Fix mixed content by:

1. Updating all hardcoded http:// URLs in your CMS or HTML to https:// or protocol-relative //.
2. Adding a Content Security Policy header with upgrade-insecure-requests as a temporary catch-all:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

1. Using browser DevTools (F12 > Console) to identify the specific offending resources.

Certificate Renewal and Lifecycle Management

For commercial certificates managed manually, set a calendar reminder 30 days before expiry. An expired certificate is worse than no certificate — browsers display a full-page blocking error that users cannot easily bypass.

If you are running multiple domains or a high-traffic application on a Dedicated Server, consider implementing a centralized certificate management solution such as cert-manager (Kubernetes), Vault PKI, or a wildcard certificate to reduce renewal overhead across subdomains.

Decision Matrix: Which Installation Method to Use

Technical Key-Takeaway Checklist

• Confirm port 443 is open in your firewall before installing any certificate.
• Always verify the private key matches the certificate before installation: openssl x509 -noout -modulus -in certificate.crt | md5sum and openssl rsa -noout -modulus -in private.key | md5sum must produce identical hashes.
• Include the full intermediate chain (ca_bundle.crt) — omitting it causes trust failures on mobile browsers even when desktop Chrome shows a padlock.
• Set chmod 600 on the private key file; never expose it in a web-accessible directory.
• Disable TLS 1.0 and TLS 1.1 in your web server configuration — these protocols are deprecated and exploitable.
• Enable HSTS with includeSubDomains only after confirming all subdomains also serve HTTPS.
• Run certbot renew --dry-run after initial Certbot setup to confirm the renewal pipeline works.
• Test with SSL Labs after every installation or configuration change.
• Audit for mixed content immediately after switching to HTTPS — it silently breaks functionality.
• For Let's Encrypt wildcard certificates, use the DNS-01 challenge, not HTTP-01.

Frequently Asked Questions

What is the difference between an SSL certificate and a TLS certificate?

SSL (Secure Sockets Layer) is the legacy protocol that was deprecated in 1999. Its successor, TLS (Transport Layer Security), is what all modern HTTPS connections actually use. The term "SSL certificate" persists as industry shorthand, but every certificate issued today operates over TLS 1.2 or TLS 1.3.

Why does my SSL certificate show as trusted on Chrome but not on Android devices?

This is almost always a missing intermediate certificate chain. Desktop Chrome has an aggressive certificate fetching mechanism (AIA fetching) that can reconstruct the chain even when it is absent from the server. Android's system store does not. Always include the ca_bundle.crt chain file in your server configuration.

Can I install an SSL certificate on a domain that does not have a website yet?

Yes, but only if the domain's DNS A record resolves to the server's IP address. The CA must be able to reach the server to complete domain validation. If DNS is not yet propagated, the challenge will fail.

How do I renew a commercial SSL certificate without downtime?

Generate a new CSR on the server, submit it to your CA, receive the new certificate bundle, replace the certificate files on the server, and reload the web server (systemctl reload apache2 or systemctl reload nginx). A reload applies the new certificate without dropping existing connections, unlike a full restart.

Does installing an SSL certificate automatically redirect HTTP to HTTPS?

No. Installing a certificate only enables HTTPS. The HTTP-to-HTTPS redirect must be configured separately in your virtual host or server block. Certbot's --apache and --nginx plugins offer to configure this redirect automatically during installation. For manual installations, add an explicit Redirect permanent (Apache) or return 301 (Nginx) directive in the port 80 server block.