Manually Install an SSL Certificate: Nginx, Apache, IIS

If your site still throws "Not secure" warnings or breaks on https, you’re leaking trust, rankings, and revenue. Here’s a practical, operator-grade playbook to manually install an SSL/TLS certificate on common servers (Nginx, Apache, IIS, Node), avoid chain errors, force secure redirects, and set up a renewal process that doesn’t wake you up at midnight on expiry day.

SSL is not a checkbox. Browsers flag non-HTTPS sites, which tanks trust on landing. If you buy paid traffic or run outbound to book demos, you’re paying for clicks that bounce on a warning screen. That’s a direct hit to CAC and pipeline quality.

Search engines reward secure experiences. HTTPS is a lightweight ranking signal, but it compounds with site speed, Core Web Vitals, and crawlability. If you care about organic visibility, you need stable, correct TLS with no mixed-content errors.

SSL also affects conversion mechanics: secure cookies, consistent canonical URLs, and checkout trust badges. For e-commerce and lead forms, HTTPS plus good UX usually bumps completion rates - another path to more sales without touching ad spend.

At a high level, your server presents a certificate to the browser. The browser checks if a known Certificate Authority (CA) vouches for it, then negotiates an encrypted connection. Under the hood, you manage three core elements: a private key, a certificate signing request (CSR), and the issued certificate bundle from the CA.

Your private key stays with you - never share it, never email it. You generate a CSR from the private key and send the CSR to the CA. The CA validates domain ownership (DV), organization (OV), or extended information (EV). They return a cert plus one or more intermediate certs. That intermediate chain is critical; skipping it is a top cause of “incomplete chain” errors.

Browsers trust a small list of root CAs. Your certificate is signed by an intermediate that chains to a root. If the chain is wrong, some clients (especially older Android or internal systems) fail the handshake. Always deploy full chain bundles, not “leaf-only” certs.

Domain Validation (DV) is enough for most marketing sites and apps. It’s cheap or free (Let’s Encrypt) and validates control over the domain. Organization Validation (OV) and Extended Validation (EV) add identity verification and, in some cases, visible UI cues, but modern browsers have downplayed EV indicators. Use OV/EV for audited or regulated deployments if required by policy.

Wildcard certificates (*.example.com) cover a root domain and its first-level subdomains. They’re handy when you spin up many subdomains (app.example.com, status.example.com). Subject Alternative Name (SAN) certificates cover multiple named hosts across domains or subdomains (www.example.com, example.com, example.org). Choose SAN when you need discrete hostnames under one cert.

Also consider infrastructure shape. If you terminate TLS at a load balancer or CDN (Cloudflare/AWS ALB), you might need one certificate there and optionally another between the proxy and your origin (Full/Strict modes). Align cert scope with where the TLS handshake actually happens.

Before touching servers, list every hostname that must resolve over HTTPS, and where TLS terminates. Include www/non-www, app subdomains, API hosts, and any vanity domains from campaigns. If you miss one, users will hit mixed experiences or certificate mismatch errors.

Collect the expected file formats. Most Linux stacks use PEM (.pem/.crt) for certs and .key for private keys. Windows/IIS typically prefers PFX/PKCS#12 (.pfx) with an exportable private key. If your CA gave you .cer/.der, you can often convert via OpenSSL.

Confirm you have SSH/RDP access, sudo rights, and firewall permissions for 443. If DNS or CDN changes are needed, have those credentials ready. For staged cutovers, plan a short maintenance window or blue/green approach to avoid half-configured states under traffic.

On Linux/macOS with OpenSSL, create a private key and CSR. Use 2048-bit RSA as a minimum (RSA 3072 or ECDSA P-256/P-384 are also common). Example:

# RSA 2048 private key
openssl genrsa -out example.com.key 2048

# CSR with subject; adjust fields as needed
openssl req -new -key example.com.key -out example.com.csr \
  -subj "/C=AE/ST=Dubai/L=Dubai/O=Example LLC/CN=example.com"

If you need SANs (e.g., example.com and www.example.com), prepare an OpenSSL config with subjectAltName and pass it during CSR creation. Many CAs also let you specify SANs in their UI and will provide a ready-made CSR template if you upload your key.

On Windows for IIS, you can generate a CSR via IIS Manager (Server Certificates → Create Certificate Request). After the CA issues the cert, complete the request in the same pane and export to PFX if you’ll deploy to multiple servers.

With your issued certificate and CA bundle in hand, copy files to a secure path on the server, e.g., /etc/ssl/certs and /etc/ssl/private. Verify permissions: the private key should be readable only by root (e.g., 600).

Point Nginx to your full chain. Some CAs give a single fullchain.pem. If not, concatenate your leaf cert and the intermediate(s) in the correct order: leaf first, then intermediates. Example server block:

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

  ssl_certificate     /etc/ssl/certs/fullchain.pem;    # leaf + intermediates
  ssl_certificate_key /etc/ssl/private/example.com.key;

  # Recommended minimums
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:50m;

  # OCSP stapling (if supported by your CA)
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 1.1.1.1 8.8.8.8 valid=300s;

  root /var/www/example;
  index index.html index.htm;
}

# Redirect HTTP to HTTPS
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://$host$request_uri;
}

Test and reload: nginx -t then systemctl reload nginx. If you host multiple domains, ensure Server Name Indication (SNI) is supported (it is on modern Nginx), and each server_name block references the correct key/cert pair. A mis-ordered default_server can present the wrong cert.

Enable mod_ssl and http2 if applicable. Place the cert, key, and chain files under /etc/ssl and reference them in your VirtualHost. For full chain, either use SSLCertificateChainFile (older distros) or concatenate your chain to the cert file (newer Apache expects SSLCertificateFile to contain full chain).

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

  DocumentRoot /var/www/example

  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/fullchain.pem       # leaf + intermediates
  SSLCertificateKeyFile /etc/ssl/private/example.com.key

  Protocols h2 http/1.1

  # Optional hardening
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

  # OCSP Stapling
  SSLUseStapling on
  SSLStaplingCache shmcb:/var/run/ocsp(128000)
</VirtualHost>

# Redirect HTTP to HTTPS
<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com
  Redirect permanent / https://example.com/
</VirtualHost>

Run apachectl configtest and systemctl reload httpd (or apache2) to apply. If you see chain errors on SSL Labs, check the order of the intermediate certificates or replace SSLCertificateFile with a properly concatenated fullchain.

After your CA issues the certificate, complete it in IIS Manager: Server Certificates → Complete Certificate Request. If you instead receive a PFX, import it there and mark the private key as exportable if you expect to reuse it on other nodes.

Next, bind HTTPS to your site: Sites → YourSite → Bindings → Add → Type: https, Host name: example.com (and add www as another binding if needed), select the imported certificate. Check SNI if you’re hosting multiple sites on the same IP.

To enable strong protocols, use the registry or a tool like IIS Crypto to disable TLS 1.0/1.1 and old ciphers. Add HSTS via web.config or HTTP Response Headers. Confirm Windows Update includes the latest trusted roots to avoid client trust issues.

If Node terminates TLS directly (not behind Nginx/ALB), use the https module and pass key and cert (full chain) buffers. Example:

const fs = require('fs');
const https = require('https');
const app = require('./app');

const options = {
  key: fs.readFileSync('/etc/ssl/private/example.com.key'),
  cert: fs.readFileSync('/etc/ssl/certs/fullchain.pem') // leaf + intermediates
};

https.createServer(options, app).listen(443, () => {
  console.log('HTTPS server running');
});

In production, it’s common to terminate TLS at Nginx, a cloud load balancer, or a CDN and run Node behind it on HTTP. If you do, set trust proxy in Express to honor X-Forwarded-Proto and ensure cookies are marked Secure only when the client connection is HTTPS.

Whatever your topology, pick a single TLS termination point per request path to simplify cert management. Double-terminations add complexity without clear user value unless you enforce end-to-end encryption for compliance.

Force a single canonical scheme/host. Choose www or non-www, then redirect everything else to that host on HTTPS. Inconsistent canonicalization splits authority across URLs and muddles analytics. Use 301 permanent redirects.

Enable HSTS (Strict-Transport-Security) cautiously. Start with max-age=300 then raise to max-age=31536000 and includeSubDomains once you’re sure every subdomain supports HTTPS. Preload is powerful but sticky - only enable when you’re committed long-term.

Mark session and auth cookies as Secure and set SameSite appropriately (Lax or Strict unless cross-site flows require None; Secure). This prevents cookie leakage over HTTP and mitigates some CSRF patterns.

After enabling HTTPS, scan pages for mixed content - HTTP images, scripts, or fonts. Modern browsers block “active” mixed content, breaking features. Update asset URLs to protocol-relative or explicit HTTPS. Many CDNs also provide rewrite rules to auto-upgrade.

Update canonical tags, hreflang, and sitemap.xml to HTTPS. Inconsistent signals confuse crawlers and can slow reindexing. For GA4/Amplitude and ad pixels, verify secure endpoints and cross-domain settings still behave under HTTPS.

If you’re migrating a legacy site, crawl the old HTTP structure and confirm all URLs 301 to the correct HTTPS equivalent. Watch for redirect chains (HTTP → www HTTP → HTTPS). Flatten them to a single hop.

Cloud providers make TLS easier but add decisions. On AWS, you can issue certs via AWS Certificate Manager and attach to ALB/CloudFront. Decide between SNI-only vs dedicated IPs. Use “Full (strict)” equivalent modes to ensure origin certs are valid when terminating at the edge.

On Cloudflare, avoid Flexible mode (it encrypts only between user and Cloudflare, not Cloudflare to origin). Use Full (strict) with a valid origin cert. If you rotate origin certs, coordinate expiry across all environments or use Cloudflare Origin CA certs dedicated to the tunnel.

In Kubernetes, terminate at an Ingress Controller (Nginx/Traefik) or a cloud LB. Store certs in Secrets (preferably via cert-manager for automation). For multi-region, replicate certs and keys securely and align DNS health checks to fail over cleanly without mismatched chains.

Manual installs fail at renewal time. If you must stay manual (e.g., security policy), calendar the expiry, set 30/14/7/1-day alerts, and test the new chain in staging. Always keep the previous cert available for rapid rollback if a new chain breaks old clients.

Let’s Encrypt automation (certbot, acme.sh) is robust and free. Even if you prefer a paid OV/EV, you can automate deployment and reloads. In containerized stacks, bake the cert into secrets and roll deployments before expiry. For Windows farms, use centralized certificate stores and Group Policy or PowerShell to distribute and bind.

Monitor with synthetic checks that validate not only port 443 but also the presented CN/SAN, chain completion, and days-to-expiry. Many outages happen because one subdomain or a forgotten API host expired quietly.

SSL sits at the intersection of infra, security, and marketing performance. If it lives only with “the dev,” it’s invisible until it hurts conversions or paid traffic. Give one person explicit ownership, define renewal SLAs, and document environments, cert sources, and termination points.

If you currently pay an agency to “handle it,” ask for the playbook: where termination occurs, what monitors run, and how renewals are tested. If the answer is vague, you’re one person’s vacation away from downtime - and that’s an agency tax you don’t need.

Operator note: I run marketing ops end-to-end - SEO, outbound, paid, sites, and the automation glue between them. The model is simple: one senior operator, outcomes over optics. Real proof: a B2B SaaS client grew from 0 to ~80K organic visits/month and ~2K inbound leads/month. If that way of working fits, read more about Anton Chisliuk · AI Marketing Ops.

Disable TLS 1.0/1.1. Support TLS 1.2 and 1.3. Prefer strong ciphers and enable HTTP/2 where possible. For public sites, Perfect Forward Secrecy is table stakes. Templates from Mozilla SSL Configuration Generator are a good baseline - then adapt for your client base.

Enable OCSP stapling to speed up trust checks. Your server caches the CA’s OCSP response and presents it to clients, reducing latency. Validate that your CA supports stapling; not all intermediates do. Keep resolvers configured so your server can fetch updates.

For multi-tenant hosts, confirm SNI is on and each vhost/binding references the correct cert. A surprising number of “wrong certificate” incidents are simply default vhost misfires after a reload.

Handshake fails? Start with the basics. Does the CN/SAN match the host? Is the private key the one used to generate the CSR? You can verify modulus matches between key and cert:

openssl rsa -noout -modulus -in example.com.key | openssl md5
openssl x509 -noout -modulus -in example.com.crt | openssl md5
# Hashes must match

Chain issues? Use SSL Labs (Qualys) to test. If it reports an incomplete chain, concatenate intermediates in the correct order or use the CA-provided fullchain. For stubborn cases, test with testssl.sh to see protocol and cipher mismatches by client profile.

Performance regressions? Check HTTP/2 status, OCSP stapling, and session reuse. Also review CDN edge settings; an origin that upgraded to TLS 1.3 while the CDN forces an older profile can create odd latency patterns.

For staging and dev, you can use separate certs or wildcard/SAN certs if the hosts are public. For private hostnames, internal PKI or self-signed works for testing but expect browser warnings unless your org roots are deployed across devices.

In autoscaling setups, don’t SSH certs manually into ephemeral instances. Store them in a secure secrets system and automate injection at boot/deploy. Reload services gracefully to avoid connection drops (e.g., nginx -s reload rather than restart).

When you rotate a key, plan revocation or let the old cert expire naturally. If you suspect key compromise, revoke immediately and deploy a new chain. Update CT monitoring (Certificate Transparency) alerts to catch unauthorized issues.

Once live, validate across devices: latest Chrome, Safari, Firefox, and an older Android profile. Confirm no mixed content, correct redirects, and HSTS present. Inspect cookies on auth paths for Secure and SameSite flags.

Set up alerts for days-to-expiry thresholds and up/down checks per critical hostname. Include a synthetic step that verifies a 200 status from HTTPS canonical hosts and expected response headers. Don’t rely on “it looks fine on my laptop.”

Tie it back to go-to-market: confirm Search Console sees the HTTPS property, resubmit sitemaps, and watch impressions/clicks for a fortnight. Marketing and infra share the same scoreboard - revenue - and HTTPS is part of that system.

Manual SSL installs aren’t glamorous, but they are unblockers for trust, rankings, and revenue. Generate the right CSR, deploy the full chain, force clean redirects, harden protocols, and set up monitoring and renewals. If you treat certificates as a living system - not a one-off ticket - you’ll avoid invisible leaks in your funnel.

If you want a pragmatic second set of eyes across site, tracking, automation, and SSL/infra touchpoints, book a free Growth Audit. We’ll tell you what to fix now, what can wait, and what drives pipeline.

Article by Anton Chisliuk - Leads, sales, content, and systems, one senior operator.

- Do I need a paid certificate, or is Let’s Encrypt enough?

For most marketing sites and apps, Let’s Encrypt (DV) is sufficient and widely trusted. If your compliance policy mandates OV/EV or you need specific warranties, go paid. Either way, the key is correct chain deployment and reliable renewals.

- What’s the difference between fullchain and cert files?

The leaf cert secures your domain, but browsers also need intermediate certs that chain to a trusted root. fullchain typically contains the leaf plus intermediates in order. Use fullchain for ssl_certificate on Nginx and SSLCertificateFile on newer Apache setups.

- Will enabling HSTS break anything?

HSTS forces HTTPS. It can break if any subdomain lacks HTTPS - especially with includeSubDomains and preload. Ramp up: start small (max-age minutes/hours), verify coverage, then extend to a year and consider preload only when you’re fully committed.

- How do I fix mixed content fast?

Search-and-replace hardcoded http:// in templates and CMS settings. Use protocol-relative or https URLs for CDNs. For large sites, a reverse proxy rule can auto-upgrade asset requests, but fix source templates to avoid regressions.

- Is TLS termination at the CDN secure enough?

Yes, for most public sites. Use Full (strict) so the CDN validates your origin cert, not Flexible. For regulated apps, you may also encrypt origin to app traffic (mTLS, private networking) depending on your threat model.

- How often should I rotate keys?

Many teams rotate keys with cert renewals (90 days for Let’s Encrypt, 12–24 months for paid). If you suspect compromise, rotate immediately and revoke the old cert. Document rotation cadence in your security policy.

- Can I use one certificate for multiple domains?

Yes, via a SAN certificate listing all hostnames. Ensure each hostname is included as a SAN entry. Wildcards cover subdomains of one domain; they won’t cover entirely different domains.

- My mobile users fail while desktop works - why?

Often an incomplete chain or an old Android trust store. Validate with SSL Labs’ Android profile. Include the proper intermediates and avoid using deprecated roots. If you rely on very new roots, some legacy devices won’t trust them.