20 Aug 2026
Nginx is widely used as a web server, reverse proxy, load balancer, and application gateway. When Nginx handles customer-facing websites, APIs, or applications, configuring HTTPS correctly is essential for protecting data in transit.
An SSL Certificate for Nginx enables encrypted communication between users and your server. Although SSL is the commonly used term, modern websites use TLS to establish secure HTTPS connections.
Installing a certificate on Nginx involves more than uploading a certificate file. You need to configure the certificate, private key, certificate chain, HTTPS listener, supported TLS protocols, and renewal process correctly.
This guide explains how to install and configure an Nginx SSL Certificate, troubleshoot common certificate problems, and manage certificates efficiently as your infrastructure grows.
Nginx can serve HTTP traffic without encryption, but applications that transmit credentials, payment information, personal data, API requests, or business information should use HTTPS.
An SSL/TLS certificate provides:
For organizations using Nginx as a reverse proxy, HTTPS is especially important because Nginx may be the first point where external traffic enters the infrastructure.
Nginx’s SSL module provides the functionality required to support HTTPS. The modern configuration uses the ssl parameter with the listen directive, such as listen 443 ssl;.
Many organizations use Nginx in front of:
In these environments, Nginx can terminate TLS at the edge and forward requests to the backend application.
APIs also require secure communication because API requests may contain authentication tokens, customer information, application data, or other sensitive information.
A properly configured Nginx SSL certificate helps establish an encrypted HTTPS connection before requests reach the backend.
The right certificate depends on the domains and services you need to protect.
A single-domain certificate protects one fully qualified domain name.
For example:
www.example.com
This is suitable when your Nginx server hosts a single primary website or application.
A wildcard certificate can protect multiple first-level subdomains.
For example:
*.example.com
It can cover:
However, a wildcard certificate for *.example.com does not automatically cover deeper subdomains such as dev.app.example.com.
A multi-domain certificate can protect multiple specified domain names under one certificate.
This can be useful when one Nginx infrastructure serves several domains.
Organizations may also choose certificates based on their validation requirements.
The certificate type should be selected based on the security, trust, compliance, and business requirements of the application.
Installing an SSL certificate on Nginx generally involves obtaining the certificate files, placing them securely on the server, configuring the Nginx server block, validating the configuration, and reloading Nginx.
After purchasing or issuing a certificate, you typically receive:
The exact files depend on the certificate authority and issuance process.
Keep the private key protected because it is the credential that allows the server to prove possession of the certificate’s corresponding private key.
Place the certificate and private key in appropriate locations with restrictive permissions.
For example:
/etc/nginx/ssl/example.com/
A possible file structure is:
example.com.crt
example.com.key
If your certificate provider supplies an intermediate certificate, you may also need to create a full certificate chain.
Nginx expects the server certificate to be followed by the intermediate certificates in the certificate file when a chain is required.
A typical full-chain file can be created by combining the server certificate and intermediate certificate:
cat example.com.crt intermediate.crt > fullchain.crt
The order matters. The server certificate should appear first, followed by the intermediate certificate or certificates.
Nginx’s documentation specifically states that when intermediate certificates are included, the primary certificate should come first, followed by the intermediates.
Open the relevant Nginx configuration file and configure HTTPS.
A basic configuration looks like:
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/nginx/ssl/example.com/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/example.com/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://localhost:3000;
}
}
The ssl_certificate directive specifies the certificate file, while ssl_certificate_key specifies the private key. Current Nginx documentation lists TLS 1.2 and TLS 1.3 as the default enabled protocols.
You can redirect HTTP traffic to HTTPS using a separate server block:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
This ensures visitors who access the HTTP version are redirected to the secure HTTPS version.
Before reloading Nginx, check the configuration:
sudo nginx -t
If the configuration test succeeds, reload Nginx:
sudo systemctl reload nginx
A reload applies the updated configuration without requiring a full service restart.
Certificate configuration problems are common when setting up HTTPS for the first time or replacing an expired certificate.
One of the most common problems is installing only the domain certificate without the required intermediate certificates.
Users may see certificate trust errors even though the certificate itself is valid.
Check whether your Nginx configuration points to a full-chain certificate.
ssl_certificate /etc/nginx/ssl/example.com/fullchain.crt;
The certificate and private key must belong together.
You can compare their public-key information using OpenSSL:
openssl x509 -noout -modulus -in certificate.crt | openssl sha256
and:
openssl rsa -noout -modulus -in private.key | openssl sha256
The resulting values should match for RSA certificates.
Nginx needs access to the certificate and private key files.
However, the private key should not be made publicly readable just to solve a permission problem.
Review file ownership and permissions instead.
If Nginx continues serving an older certificate after renewal, check:
This is a common real-world renewal problem discussed by Nginx users, particularly when certificates are renewed but the running Nginx process has not loaded the new files.
Run:
sudo nginx -t
The output usually identifies the configuration file and line containing the problem.
Do not reload a configuration until the syntax test succeeds.
SSL certificate renewal becomes increasingly important as the number of certificates increases.
Manually tracking expiration dates can result in certificates being overlooked, especially when certificates are deployed across multiple Nginx servers.
A typical renewal workflow includes:
Tools such as ACME-compatible clients can automate certificate issuance and renewal.
For automated deployment, the renewal process should also trigger an Nginx reload after the new certificate is installed.
Community discussions frequently highlight this exact issue. Renewing the certificate file alone does not necessarily mean the running Nginx process is serving the new certificate. A reload or appropriate deployment hook is required.
If you use an automated certificate management tool, test the renewal process before relying on it in production.
The goal is not simply to renew the certificate. The complete process should work from certificate issuance through deployment and Nginx reload.
Automated monitoring should provide visibility into:
This becomes particularly important when Nginx is deployed across multiple servers, environments, regions, or cloud platforms.
Managing one Nginx server is relatively straightforward.
Managing hundreds of Nginx instances is different.
Enterprise environments may have certificates across:
A centralized certificate lifecycle management approach can help organizations discover certificates, monitor expiration, control ownership, and automate deployment.
Instead of relying on spreadsheets and manual reminders, security and infrastructure teams can establish automated workflows for certificate discovery, renewal, deployment, and monitoring.
This is particularly useful when Nginx is part of a broader cloud or DevOps environment.
A secure Nginx HTTPS deployment should focus on both certificate management and TLS configuration.
Modern Nginx configurations support TLS 1.2 and TLS 1.3.
For example:
ssl_protocols TLSv1.2 TLSv1.3;
Avoid enabling outdated SSL/TLS protocols unless there is a specific compatibility requirement that has been assessed and accepted.
Nginx currently documents TLS 1.2 and TLS 1.3 as its default ssl_protocols values.
The private key should be stored securely and should only be accessible to the processes that require it.
Never publish or expose the private key through a website, source repository, public storage location, or unsecured backup.
A valid server certificate without the correct intermediate chain can still create trust problems for clients.
Always verify that the complete chain is deployed correctly.
Use:
sudo nginx -t
before applying configuration changes.
This simple step can prevent an invalid configuration from disrupting an existing Nginx deployment.
Do not wait for a browser warning to discover an expiring certificate.
Monitor certificate expiration and deployment status continuously, particularly for production applications and APIs.
When HTTPS is not working correctly, follow a structured troubleshooting process.
Confirm that the configured files exist:
ls -l /etc/nginx/ssl/example.com/
Run:
sudo nginx -t
Look for errors related to:
Use OpenSSL:
openssl x509 -in fullchain.crt -noout -dates
This displays the certificate’s validity period.
You should also verify the certificate presented by the live domain rather than checking only the local certificate file.
For example:
openssl s_client -connect example.com:443 -servername example.com
This can help identify situations where the local certificate has been renewed but Nginx is still serving an older certificate.
Nginx can host multiple domains on the same server.
If the wrong certificate appears, verify:
server_name example.com;
and make sure the correct HTTPS server block is handling the request.
Nginx uses SNI for name-based HTTPS configurations, allowing different certificates to be associated with different server names on shared infrastructure.
Manual certificate management becomes difficult as infrastructure grows.
Automation can help organizations:
The objective is not simply to automate certificate renewal.
A complete lifecycle should cover discovery, monitoring, issuance, renewal, deployment, validation, and retirement.
For organizations running Nginx across cloud, DevOps, hybrid, and multi-server environments, certificate lifecycle automation can significantly reduce operational risk.
Running HTTPS on Nginx is straightforward when you have a small number of servers. The challenge increases when certificates are distributed across multiple applications, domains, environments, and infrastructure platforms.
Flying Stars can help organizations with SSL certificate selection, deployment, monitoring, renewal, and certificate lifecycle management.
If your organization is managing multiple Nginx servers or frequently dealing with certificate expiration, manual deployment, or renewal issues, a centralized SSL management approach can help simplify operations.
Talk to an SSL certificate specialist about selecting and deploying the right certificate for your Nginx environment.
Reduce certificate expiry risks with centralized monitoring and automated certificate lifecycle management.
Yes. Nginx supports certificates in PEM format and can be configured with certificates issued by publicly trusted certificate authorities or internal PKI, depending on your use case. The certificate and private key must be configured correctly in the Nginx server block.
Typically, you need the server certificate, private key, and, when required, the intermediate certificate chain. For Nginx, the server certificate and intermediate certificates are generally placed together in the certificate file, with the server certificate first.
The most common reason is an incomplete certificate chain. If the intermediate certificate is missing from the certificate file served by Nginx, some clients may be unable to establish a trusted chain.
Renewing or replacing the certificate file does not automatically mean the running Nginx workers are serving the new certificate. Check the configured certificate path, validate the configuration with nginx -t, and reload Nginx after a successful configuration test. This is also a recurring issue in Nginx community discussions.
A full restart is generally not necessary just to load a new certificate. After confirming the configuration with nginx -t, you can normally reload Nginx so it applies the updated configuration with minimal disruption.
Store certificate and private key files in a protected location on the server and reference them from the Nginx configuration using ssl_certificate and ssl_certificate_key. For example: ssl_certificate /etc/nginx/ssl/example.com/fullchain.crt; ssl_certificate_key /etc/nginx/ssl/example.com/example.com.key;
If your certificate requires intermediate certificates, yes. Nginx’s documentation specifies that the primary certificate should be followed by the intermediate certificates in the same certificate file.
You can inspect the live TLS connection using: openssl s_client -connect example.com:443 -servername example.com You can also use browser certificate information or an external TLS testing service to inspect the certificate presented by the public server.
Yes. Nginx can serve different certificates for different domains using separate server blocks and SNI. Nginx also supports configuring multiple certificate types, such as RSA and ECDSA, when supported by the underlying OpenSSL version.
Yes. Nginx can use wildcard certificates such as *.example.com. A wildcard certificate can cover multiple first-level subdomains, making it useful when several services are hosted behind Nginx.
You can use certificate automation tools and configure the renewal workflow to deploy the new certificate and reload Nginx automatically. The important part is automating the complete process rather than only renewing the certificate.
Use continuous certificate monitoring and automated renewal. Organizations managing multiple Nginx servers should maintain a centralized inventory of certificates and monitor expiration, deployment status, and renewal failures.
The basic TLS concepts remain the same, but certificate files are commonly mounted into the Nginx container through volumes or secrets. The renewal process must also ensure that the updated certificate reaches the container and that Nginx reloads the new certificate.
Yes. Nginx can terminate HTTPS at the reverse proxy and forward traffic to an internal application. However, whether the backend connection should also use HTTPS depends on the application’s security architecture and the trust boundaries within the environment.
