How to Install an SSL Certificate (Nginx, Apache, cPanel)

What you need before you install an SSL certificate

Before you touch a server configuration file, make sure you actually have everything the certificate authority (CA) sends after domain validation is complete. Installation itself is quick; a missing file is the most common reason it fails.

• Your private key — generated on your server (or in your reseller panel) when you created the certificate signing request (CSR). Never share it, and never regenerate the CSR after issuance, or the key and certificate will no longer match.
• The certificate file — the leaf certificate for your domain, usually a .crt or .cer file.
• The CA bundle / intermediate certificates — one or more files that link your certificate to a trusted root. Skipping these causes the "chain incomplete" errors covered below.
• A PFX file (optional) — a single password-protected file bundling certificate, chain, and private key, used mainly on Windows/IIS.

What you receive also depends on the validation level — see the difference between DV, OV, and EV certificates if you're not sure which one you ordered. If you want the fundamentals first, read our guide to what SSL/TLS actually does.

Install an SSL certificate on Nginx (with the full chain)

Nginx expects one certificate file that contains your certificate and the intermediate chain, in that order — often called the "full chain." Concatenate them into a single file, then reference it and your private key in the server block:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example_com.fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
}

Build the full chain file with:

cat example_com.crt intermediate.crt >> fullchain.crt

Test the configuration before reloading, so a typo doesn't take the site down:

nginx -t && systemctl reload nginx

If you also want a hardened cipher and protocol configuration for your specific Nginx version, the Mozilla SSL Configuration Generator produces a ready-to-use snippet.

Apache 2.4 SSL configuration

Apache 2.4 uses two required directives and, on older builds, a third:

On Apache 2.4.8 and later, you can put the intermediate certificates directly inside the SSLCertificateFile, right after the leaf certificate:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example_com.fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example_com.key
</VirtualHost>

Enable the module and site, then reload: a2enmod ssl, a2ensite, followed by apachectl configtest && systemctl restart apache2.

cPanel SSL install and Windows/IIS via PFX

Most shared and reseller hosting runs through cPanel, which is why hosting providers installing SSL for many customers usually never touch a config file directly:

1. Log in to cPanel and open SSL/TLS → Manage SSL Sites.
2. Select the domain, then paste the certificate, the private key, and the CA bundle into their fields (cPanel can often auto-fill the CA bundle once it recognizes the certificate).
3. Click Install Certificate. cPanel applies it immediately — no service restart needed.

On Windows Server / IIS, the usual path is a PFX file that already bundles the certificate, chain, and private key: import it in IIS Manager under Server Certificates, then bind it to the site on port 443 (with SNI enabled if the server hosts multiple HTTPS sites on one IP address).

Redirect HTTP to HTTPS and enable HSTS

Installing the certificate only enables HTTPS; visitors typing your domain without https:// still land on port 80 unless you redirect them. On Nginx:

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

On Apache, inside the port-80 virtual host:

Redirect permanent / https://example.com/

Once every visitor reaches your site over HTTPS reliably, add HTTP Strict Transport Security so browsers skip the HTTP request entirely on future visits:

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

Roll out HSTS gradually — start with a short max-age, confirm every subdomain actually serves HTTPS, then increase it.

Test your SSL installation

Before you consider the job done, confirm the server is actually presenting the full chain. From any machine with OpenSSL installed:

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

Look at the certificate chain in the output — your certificate should be followed by the intermediate(s), and the connection should report Verify return code: 0 (ok). The -servername flag matters: it enables SNI, so you're testing the certificate for that specific hostname rather than whatever loads by default. Free online SSL checker tools give the same information in a browser-friendly report and will flag an incomplete chain, an expired certificate, or a hostname mismatch.

Common SSL installation errors and how to fix them

Most installation problems fall into a handful of categories:

• Missing intermediate certificate. The site looks fine in your desktop Chrome (which can fetch missing intermediates itself) but fails in other browsers, mobile apps, or API clients. Fix: install the full chain, not just the leaf certificate.
• Key mismatch. The private key doesn't match the certificate — usually because a new CSR was generated after the certificate was issued. Compare the modulus of both files; if they differ, you need the key that matches the certificate you actually received, or you must reissue against the current key.
• Wrong file order. When building a full-chain file, the leaf certificate must come first, followed by intermediates in order, ending with (or omitting) the root. Reversing the order breaks validation on some clients even though others tolerate it.
• Mixed content. After enabling HTTPS, pages that still load images, scripts, or stylesheets over plain http:// trigger browser warnings and a partially broken padlock icon. Fix hardcoded http:// references in your code and database.
• SNI issues. Serving multiple certificates from one IP address requires Server Name Indication; only very old clients lack SNI support today, but if the wrong certificate is served, check that server_name / ServerName matches exactly and that the correct server block is being selected.

Renewals and automation now that certificates last 200 days

Public certificate lifetimes are shrinking under the CA/Browser Forum's Ballot SC-081: a maximum of 200 days for certificates issued from March 15, 2026, dropping to 100 days in 2027 and 47 days by 2029. That schedule makes manual, once-a-year installation unrealistic — reinstalling every few months by hand doesn't scale past a handful of sites, which is exactly why digital agencies and hosting providers managing many client domains are moving renewal onto automation.

Options include ACME clients that renew and reload the web server automatically, or scripted certificate management through a REST API that lists products, places orders, and downloads the reissued certificate as soon as it's ready. See our detailed look at why SSL certificate validity is shrinking for the full timeline and what it means for your renewal process.

Get the right certificate, then install it once

Installation is straightforward once you have the right files in the right place — certificate, full chain, and matching private key — and confirm it with a quick openssl s_client check. What takes more planning is choosing the right certificate type and keeping renewals on schedule as validity periods keep shrinking.

If you're still deciding which certificate to buy, SSLCipher's reseller pricing page lists current prices for DV, OV, EV, Wildcard, and Multi-Domain SSL from several CAs, visible without signing up first.

Frequently asked questions