How to Install an SSL Certificate, Step by Step

Before You Start: What You Actually Need

Installing an SSL/TLS certificate has five real steps: generate a key pair and a CSR, validate domain ownership, receive the certificate, install it (cert + private key + chain) on your server, then force HTTPS and verify. Most of the confusion comes from doing them out of order or skipping the chain.

Before you begin, confirm three things. First, you control DNS for the domain and can reach the server over SSH or a control panel. Second, you know which web server you run — Apache, Nginx, or a managed panel like cPanel/Plesk — because the install location differs. Third, you decide between a free certificate (Let's Encrypt, 90-day, auto-renewing) and a paid one (1-year, with OV/EV validation or a warranty). For most sites, free DV certificates are exactly as secure as paid ones; the cryptography is identical.

• A private key (kept secret, never shared) and a matching CSR
• Domain validation access — DNS records or an email on the domain
• Your web server type and root/sudo or control-panel access
• The certificate file plus the intermediate (chain/CA bundle) file

Step 1: Generate a Private Key and CSR

A Certificate Signing Request (CSR) bundles your public key and domain details for the Certificate Authority (CA) to sign. Your private key stays on the server — it is never sent to anyone. On any Linux server with OpenSSL, one command creates both:

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

Fill in the Common Name (CN) as your exact domain — example.com or www.example.com — and the organization fields. For a wildcard, use *.example.com. If you use a control panel (cPanel > SSL/TLS, or Plesk), it generates the key and CSR for you through a form; you never touch OpenSSL. If you are using Let's Encrypt via Certbot, you can skip this step entirely — Certbot generates the key and CSR automatically.

• Use RSA 2048-bit (or ECDSA P-256) — both are current and widely supported
• -nodes means no passphrase on the key, so the server can restart unattended
• Back up the .key file securely; if you lose it, the certificate is useless

Step 2: Submit, Validate, and Receive the Certificate

Paste the CSR into your CA's order form (or let Certbot/ACME handle it). The CA then needs to prove you control the domain. Domain Validation (DV) is automatic and takes seconds to minutes via one of three methods: a DNS TXT record you add, an HTTP file the CA fetches from your site, or an approval email to admin@yourdomain. Organization (OV) and Extended (EV) validation add business checks and take 1-5 business days.

Once validated, the CA issues your certificate. You'll receive (or download) two things that both matter: your domain certificate and the intermediate/chain certificate (sometimes a combined CA bundle). The chain is what links your certificate back to a trusted root. Skipping it is the single most common install error — it often looks fine in a desktop browser but breaks on mobile and in API clients.

Step 3: Install the Certificate on Your Server

Where the files go depends on your stack. On Nginx, point the server block at the certificate and key, and crucially use the full-chain file (your cert + intermediates concatenated) so clients get the complete path:

ssl_certificate /etc/ssl/example.com.fullchain.pem; ssl_certificate_key /etc/ssl/example.com.key; listen 443 ssl;

Then run nginx -t to test the config and reload. On Apache, set SSLCertificateFile (your cert), SSLCertificateKeyFile (your key), and SSLCertificateChainFile (the intermediate) in the SSL virtual host, then apachectl configtest and restart. On cPanel or Plesk, paste the certificate, the private key, and the CA bundle into the three boxes under SSL/TLS and click install — the panel writes the files for you. If you're on Let's Encrypt, certbot --nginx or certbot --apache installs and configures everything in one command.

• Nginx: use the combined fullchain.pem, not just the leaf certificate
• Apache: keep cert, key, and chain in three separate directives
• Make sure port 443 is open in your firewall/security group
• Restart the web server — config changes don't apply until you reload

Step 4: Force HTTPS and Verify the Install

A working certificate isn't enough if visitors can still reach the plain-HTTP version. Redirect all HTTP traffic to HTTPS with a permanent 301 (an Nginx return 301 https://$host$request_uri; on port 80, or RewriteRule in Apache/.htaccess). Then add HSTS — Strict-Transport-Security: max-age=31536000; includeSubDomains — so browsers refuse to load the insecure version at all. Start with a short max-age while you confirm everything works, since HSTS is hard to undo.

Now verify. Load your site and check for the padlock, then run an external test — SSL Labs (ssllabs.com/ssltest) grades your config and flags a missing chain or weak protocol; aim for an A. From the command line, openssl s_client -connect example.com:443 -servername example.com shows the full chain the server actually sends. Finally, hunt for mixed-content warnings: any image, script, or stylesheet still loaded over http:// will break the padlock. Update those URLs to https:// or protocol-relative paths.

• 301-redirect HTTP to HTTPS so there's one canonical, secure URL
• Add HSTS after you've confirmed HTTPS works site-wide
• Fix mixed content — search your code/database for http:// asset links
• Re-run SSL Labs after changes; target an A grade with the full chain

Renewal, Common Errors, and Getting It Done Right

Certificates expire — Let's Encrypt every 90 days, paid certs every 398 days max. An expired certificate throws a full-page browser warning that scares off every visitor, so automate renewal. Certbot installs a systemd timer or cron job that renews automatically; for paid certs, set a calendar reminder 30 days out and re-install the new file. Test the renewal path before you need it: certbot renew --dry-run.

The errors you'll most likely hit: NET::ERR_CERT_AUTHORITY_INVALID usually means a missing intermediate chain (re-install with the full chain). A name mismatch means the certificate's domain doesn't match the URL (check www vs. non-www, and that wildcards cover the subdomain). 'Connection refused' on 443 is almost always a firewall or a web server not listening on the SSL port. And if the padlock has a warning triangle, it's mixed content — not the certificate itself.

None of this is hard, but it's fiddly, and a single missed step shows up as a scary warning to your visitors. If you'd rather not manage CSRs, chains, and renewals yourself, NordicVentures issues and installs SSL certificates with auto-renewal, free migration, and 24/7 human support on NVMe servers across Stockholm, Frankfurt, and Ashburn — so HTTPS is handled and stays handled.