Installing an SSL Certificate on NGINX

NGINX powers a large share of the web, and installing an SSL Certificate on it comes down to three things done correctly.

You need a properly ordered bundle file, a server block that points to the right files, and a clean configuration test before reload. This guide walks through each stage and explains why each step matters, so a failed handshake never leaves you guessing.

Many guides found elsewhere still show deprecated directives such as ssl on and outdated protocol versions. The configuration shown here reflects current NGINX releases and modern Transport Layer Security (TLS) practice.

Prerequisites and Required Files

Before touching any configuration, gather the pieces the installation depends on. You need shell access to the server with permission to edit the NGINX configuration and reload the service.

You also need your issued SSL Certificate file, usually named after your domain with a .crt extension, together with the ca-bundle file containing the Intermediate Certificates. Both are available in the tracking system once issuance is complete. View Our Tracking & SSL Management 🔗

The final piece is the Private Key that was created on your server at the same time as your Certificate Signing Request (CSR). The Private Key never leaves your server during issuance, and Trustico® does not retain a copy, so confirm the file exists before you begin. Learn About Generating a CSR 🔗

Building the SSL Certificate Bundle

NGINX expects the server SSL Certificate and the Intermediate Certificates in a single file. Unlike Apache, there is no separate chain directive, so the files must be concatenated before they are referenced in the configuration.

Run the following command in the directory containing both files.

cat yourdomain.crt yourdomain.ca-bundle > ssl-bundle.crt

Move the bundle and your Private Key into a dedicated directory such as /etc/nginx/ssl/ and restrict the permissions on the Private Key so that only the root user can read it.

chmod 600 /etc/nginx/ssl/yourdomain.key

Configuring the NGINX Server Block

With the files in place, the server block ties everything together. Modern NGINX releases declare Secure Sockets Layer (SSL) support on the listen directive itself rather than through the old standalone directive, and the protocol list should be limited to current versions.

# /etc/nginx/conf.d/yourdomain.conf
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate /etc/nginx/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/yourdomain.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

The server_name directive should list every hostname the SSL Certificate covers. A single site SSL Certificate covering the root domain and the www subdomain needs both names present, otherwise visitors reaching the unlisted name may be served the wrong site or an SSL Certificate mismatch warning.

Wildcard SSL Certificates and Multi-Domain SSL Certificates follow the same pattern. Each server block that serves a covered hostname references the same bundle and Private Key files, so one set of files can secure many server blocks. Explore Our Wildcard SSL Certificates 🔗

Testing and Applying the Configuration

NGINX validates configuration syntax without interrupting running traffic, and this test should never be skipped. A reload against a broken configuration can take a busy site offline.

sudo nginx -t

A successful test reports that the syntax is ok and the test is successful. Apply the new configuration with a reload, which picks up the changes without dropping existing connections.

sudo systemctl reload nginx

Verifying the Installation

Open your site in a browser over HTTPS and inspect the padlock to confirm the SSL Certificate details, the covered hostnames, and the expiry date. A browser check alone is not conclusive, because desktop browsers cache Intermediate Certificates and can hide an incomplete chain that will still fail on mobile devices and older clients.

An external scan checks the chain as a fresh client sees it and confirms the protocol configuration at the same time. Trustico® provides free SSL checking tools for exactly this purpose. Explore Our Trustico® SSL Tools 🔗

Troubleshooting Common Installation Problems

A few failure patterns account for nearly every NGINX installation issue, and each has a quick diagnosis.

A key values mismatch error on reload means the Private Key does not pair with the first SSL Certificate in the bundle file. This happens when the bundle was concatenated in the wrong order, or when the SSL Certificate was issued from a different CSR than the one that produced the key on this server.

Rebuild the bundle in the correct order first, and if the mismatch persists a reissue against a fresh CSR resolves it. Learn About Reissuing Your SSL Certificate 🔗

Chain errors reported by mobile devices while desktop browsers show no warning indicate the ca-bundle was never concatenated and only the bare SSL Certificate is being served. Rebuild the bundle file with both components and reload. Learn About Intermediate Certificates 🔗

If the site simply does not respond on HTTPS, confirm that port 443 is open in your firewall and that no other service holds the port. The command ss -tlnp lists listening services and quickly shows a conflict.

Professional Installation Assistance

Most NGINX installations complete in minutes once the bundle is built correctly, but production environments with load balancers, multiple server blocks, or strict change windows sometimes warrant an expert pair of hands.

Trustico® offers a Premium Installation service where our technicians complete the installation on your behalf. Discover Our Premium Installation Service 🔗