How to Set Up an SSL Certificate in Nginx (Step-by-Step Guide)

Serving a site over plain HTTP in 2026 means browsers flag it as insecure before anyone reads a word of it. Setting up SSL on Nginx takes about fifteen minutes.

There are two paths. Certbot with Let's Encrypt is free, automated, and renews itself — this is the right choice for almost everyone. A purchased commercial certificate involves manual file handling and is only necessary in specific cases. This guide covers both.

Before You Start

You need a domain with an A record pointing at your server's public IP. DNS must have propagated. Certificate issuance verifies domain ownership, and it will fail if DNS is not resolving yet.

Ports 80 and 443 must be open in your firewall and any cloud security group. Port 80 is required for the initial validation even though your site will end up on 443.

You need root or sudo access, and Nginx already installed and running.

Which Certificate Do You Actually Need?

Let's Encrypt is free, issues in seconds, and auto-renews every 90 days. It provides domain validation, which is exactly the same encryption strength as any paid certificate. For the vast majority of sites, this is the correct answer.

A commercial certificate is worth paying for in three situations. You need Organisation Validation or Extended Validation, where the certificate authority verifies your legal entity. You need a warranty and paid support for compliance reasons. Or you need a multi-year wildcard managed outside your server.

Encryption is identical across all of them. What you pay for is the validation process and the paperwork, not stronger security.

Path A: Let's Encrypt with Certbot

Step 1: Install Certbot

On Ubuntu or Debian, the snap package is what Let's Encrypt recommends:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

The apt package exists but tends to lag behind.

Step 2: Run Certbot

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

Certbot verifies domain ownership, obtains the certificate, edits your Nginx config to use it, and sets up the HTTP-to-HTTPS redirect. All of it.

When prompted about redirecting HTTP traffic, choose redirect.

Step 3: Confirm Auto-Renewal

sudo certbot renew --dry-run

Certificates last 90 days. The installer adds a systemd timer that renews at around 60 days. The dry run confirms it works. If you skip this check and renewal is broken, you find out when the certificate expires.

Verify the timer is active:

sudo systemctl list-timers | grep certbot

That is the whole process for most sites. Everything below is for people using a purchased certificate.

Path B: Installing a Purchased Certificate

Step 1: Generate a CSR and Private Key

On your server:

sudo mkdir -p /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Fill in the prompts. Common Name must be your exact domain. For a wildcard, use *.yourdomain.com.

The private key never leaves your server. Any vendor asking you to upload it is doing something wrong.

Step 2: Submit the CSR and Collect Your Files

Paste the contents of the .csr file into your certificate authority's order form. Complete their validation.

You will receive back your domain certificate and one or more intermediate certificates, sometimes called a CA bundle.

Step 3: Build the Certificate Chain

Nginx needs the domain certificate and the intermediates in a single file, in the correct order. Your certificate first, then the intermediates:

sudo cat yourdomain.crt intermediate.crt root.crt > yourdomain-chained.crt

Order matters. Reversed, browsers will report an incomplete chain — and desktop Chrome often hides the problem while mobile browsers and API clients fail hard. This is the single most common mistake with manual installs.

Step 4: Set Permissions

sudo chmod 600 /etc/nginx/ssl/yourdomain.key
sudo chown root:root /etc/nginx/ssl/yourdomain.key

A world-readable private key means anyone with shell access can impersonate your site.

Configuring the Nginx Server Block

Open your site config, typically at /etc/nginx/sites-available/yourdomain.com:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
server {
    listen 443 ssl;
    http2 on;
    server_name yourdomain.com www.yourdomain.com;
    ssl_certificate     /etc/nginx/ssl/yourdomain-chained.crt;
    ssl_certificate_key /etc/nginx/ssl/yourdomain.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    add_header Strict-Transport-Security "max-age=63072000" always;
    root /var/www/yourdomain;
    index index.html;
}
server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

A few notes on that config.

The listen 443 ssl http2 one-liner is deprecated in Nginx 1.25 and later. Use the separate http2 on; directive shown above. Plenty of older tutorials still show the old form and it now produces a warning.

TLS 1.0 and 1.1 are omitted deliberately. Both are deprecated and will fail a PCI compliance scan.

ssl_prefer_server_ciphers off is correct for modern setups. TLS 1.3 clients pick sensibly on their own.

Start HSTS with a short max-age while testing. Once a browser has seen the header, it refuses plain HTTP for that duration and there is no way to undo it from the server side. Only add includeSubDomains and preload once you are certain every subdomain serves HTTPS.

Testing and Reloading

Always test before reloading:

sudo nginx -t

If it reports the syntax is ok and the test is successful:

sudo systemctl reload nginx

Use reload rather than restart. Reload applies the new config without dropping active connections.

Verifying the Installation

Check the chain from the command line:

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

Look for "Verify return code: 0 (ok)" at the end of the output. Anything else means a chain problem.

Then run your domain through SSL Labs' server test. Aim for an A. If you score lower, the report tells you which directive is responsible.

Check your site in a browser too, on mobile as well as desktop. Mobile browsers are stricter about incomplete chains and will surface problems desktop Chrome quietly tolerates.

Common Nginx SSL Errors

SSL_ERROR_RX_RECORD_TOO_LONG — you are serving plain HTTP on port 443. The ssl parameter is missing from your listen directive.

ERR_CERT_AUTHORITY_INVALID — the intermediate certificates are missing or in the wrong order. Rebuild the chained file.

nginx: [emerg] cannot load certificate ... PEM_read_bio_X509 — the file path is wrong, or the file has Windows line endings from being edited on a desktop. Run dos2unix on it.

ERR_SSL_KEY_MISMATCH — the certificate does not match the private key. Compare the modulus hashes of both files with openssl x509 -noout -modulus and openssl rsa -noout -modulus. They must match.

Certbot fails with "Timeout during connect" — port 80 is blocked. Check both your server firewall and your cloud provider's security group.

Padlock shows but some resources are blocked — mixed content. Something on the page is still loading over HTTP. Check the browser console.

Keeping It Working

Set a calendar reminder before expiry even with auto-renewal enabled. Renewals fail silently when firewall rules change or a config edit breaks the challenge path.

Monitor the certificate externally. Uptime tools with certificate expiry checks catch what your server will not tell you.

Redirect HTTP to HTTPS at the server level rather than in application code. It is faster and it cannot be bypassed by a routing bug.

If you sit behind Cloudflare or a load balancer, know which layer terminates TLS. Origin certificate misconfigurations behind a proxy are a common and confusing failure mode.

Where This Fits in a Real Project

TLS is one layer. Security headers, rate limiting, and keeping the server patched matter alongside it.

Our team configures and maintains production infrastructure for client software, from Nginx and TLS through to CI and observability. You can see the stack we work across on our technologies page and browse shipped work in our projects portfolio.

If you are setting up the rest of the environment, the NVM on Windows tutorial covers Node version management, and the S3 backup guide handles data protection on AWS.

More walkthroughs are on the tutorials hub, and longer technical writing lives on the blog.