Install a Third-Party SSL Certificate on Nginx for WordPress

Installing a third-party SSL/TLS certificate on Nginx lets visitors connect to your WordPress site over HTTPS, protecting traffic in transit and removing browser warnings when the certificate is valid. You’ll add the certificate and private key to the server, configure Nginx to use them, test the configuration, and then check WordPress and the site’s HTTP-to-HTTPS redirect.

What You’ll Need

• SSH access to the server with permission to edit Nginx configuration and reload the service; use a sudo-capable account if required.
• A certificate issued for the exact domain names visitors use, such as example.com and, if needed, www.example.com.
• The matching private key created when the certificate request was generated, plus any intermediate certificate files supplied by the certificate authority.
• The location of your active Nginx server block and a recent backup of its configuration.
• DNS for the domain pointing to this server, and access to the certificate provider’s installation instructions if its file formats differ.

Step-by-Step

1. Identify the active Nginx configuration. Connect over SSH and inspect the server’s configuration. Common locations include /etc/nginx/sites-available/ and /etc/nginx/conf.d/, but hosting systems may use different paths. Run sudo nginx -T to print the loaded configuration and look for the server_name matching your domain. Treat its output as sensitive: configurations can contain credentials. Back up the relevant file before editing, for example with sudo cp /path/to/site.conf /path/to/site.conf.bak.
2. Check the certificate and key files. The certificate authority may provide a server certificate and one or more intermediate certificates. Nginx normally needs a full-chain certificate file: the server certificate followed by the intermediate certificate or certificates. Use the provider’s specified order and format. The private key must match the certificate and must not be shared or pasted into public tools. If the provider supplies separate files, create the full-chain file as directed, or use its existing full-chain file. Keep the key readable by the Nginx process but restrict access to authorized administrators; do not make it world-readable.
3. Place files in a stable, protected location. Store the full-chain certificate and private key in the paths recommended by your server administrator or hosting provider. For example, a system might use /etc/ssl/, but do not assume that directory is correct for every host. Record the exact paths. Avoid moving or renaming files managed by automatic renewal unless you understand how that system expects them to be arranged.
4. Edit the HTTPS server block. In the server block for the domain, configure a listener on port 443 with TLS enabled. A typical pattern is:
   server {
  listen 443 ssl;
  server_name example.com www.example.com;
  ssl_certificate /path/to/fullchain.pem;
  ssl_certificate_key /path/to/private.key;
  # Keep the existing WordPress root and PHP handling here.
}
   Replace the example names and paths. Preserve the site’s existing WordPress document root, PHP-FPM settings, and other required directives. If your configuration already has an HTTPS block, update it instead of creating a conflicting duplicate. Use current TLS settings recommended by your operating system or hosting provider rather than copying an old, unexplained cipher configuration.
5. Keep a separate HTTP block for redirects, if appropriate. Once HTTPS works, port 80 can redirect requests to the same host and path over HTTPS. A common pattern is return 301 https://$host$request_uri; in the HTTP server block. First confirm that the HTTPS block works and that the certificate covers the hostname being redirected. If you use a proxy, load balancer, or a host that terminates TLS elsewhere, follow that architecture’s guidance; an unconditional redirect can create a loop when proxy headers are not configured correctly.
6. Test before reloading Nginx. Run sudo nginx -t. Do not reload if the test reports an error. Correct file paths, missing semicolons, duplicate listeners, and permission problems, then test again. When the test succeeds, apply the configuration with sudo systemctl reload nginx on systems using systemd. If your host uses a control panel or a different service manager, use its supported reload method. A reload applies changes without intentionally stopping active connections.
7. Verify HTTPS and the certificate chain. Visit https://example.com and every other hostname you serve, including www if applicable. Check the browser’s connection details for a valid certificate, correct domain, and unexpired dates. You can also inspect the response with curl -I https://example.com or use an SSL diagnostic service. Confirm that the certificate chain is complete and that HTTP requests redirect once to the correct HTTPS URL.
8. Update WordPress only after HTTPS is confirmed. In the WordPress dashboard, open Settings > General and set both WordPress Address (URL) and Site Address (URL) to the intended HTTPS URL. If the dashboard is inaccessible or the site uses environment-managed settings, update the appropriate configuration method instead. Back up first. Then check pages, images, login, and the admin area for mixed content—resources still requested over HTTP. Update old links or use a suitable WordPress migration process, and clear relevant caches.
9. Plan for renewal. Note the certificate’s expiry date and how it will be renewed. Some third-party certificates renew through a provider or hosting panel; others require replacing files and reloading Nginx. Confirm that renewal updates the same certificate paths, includes the intermediate chain, and has a tested reload process. A certificate that expires or is replaced without a reload can cause browser errors.

Common Mistakes

• Using the server certificate without its intermediate certificates, which can make the chain appear incomplete.
• Configuring a certificate for only one hostname when visitors also use another, such as www.
• Pointing Nginx at a private key that does not match the certificate, or changing file permissions so Nginx cannot read it.
• Replacing the whole WordPress server block and accidentally removing its document root, PHP handling, or security rules.
• Enabling a redirect before HTTPS is functional, or creating a redirect loop behind a proxy.
• Changing WordPress URLs before the certificate is valid, which can make the dashboard difficult to reach.

Tips

• Keep a dated copy of the working Nginx configuration and note which certificate file is used by each hostname.
• Use sudo nginx -T to understand what Nginx actually loads, rather than editing a similarly named but inactive file.
• Make one change at a time, run nginx -t, and keep a way to restore the backup if the site becomes unavailable.
• Use HTTPS consistently for canonical URLs, WordPress settings, internal links, and any CDN or reverse-proxy configuration.

Troubleshooting

• Nginx test reports a certificate or key error: Recheck the paths, file ownership and permissions, file format, and whether the private key matches the certificate. Ensure the configured certificate file contains the full chain in the provider’s required order.
• Browser says the certificate is untrusted: Check that intermediate certificates are included, the server is presenting the intended certificate, and the system clock is correct. If a CDN or proxy handles HTTPS, check its certificate configuration too.
• Certificate name does not match: Confirm the requested hostname is listed in the certificate and in the applicable Nginx server_name. A certificate for the bare domain does not automatically cover www.
• HTTPS works but the site redirects repeatedly: Review redirects in Nginx, WordPress, plugins, and any proxy. Configure the proxy’s HTTPS forwarding information correctly; avoid adding repeated redirect rules in multiple layers.
• Some images or scripts still load over HTTP: Find the old URLs in page source or browser developer tools, update stored links carefully, and clear caches. Do not disable browser protections to hide mixed-content warnings.
• The change causes an outage: Restore the backed-up configuration, run sudo nginx -t, and reload only after it passes. If your host manages Nginx, contact its administrator or support team before making further edits.

Frequently Asked Questions

Do I need to restart Nginx after installing the certificate?
Usually, a successful configuration test followed by an Nginx reload is sufficient. Use the service method supported by your server.

Should I upload the private key to WordPress?
No. The key belongs on the server in a protected location and is referenced by Nginx. Do not put it in WordPress files, media uploads, or public repositories.

Can I use one certificate for the domain and www subdomain?
Yes, if the certificate explicitly covers both names, either as separate names or through an applicable wildcard. Configure Nginx for each hostname as needed.

Does installing the certificate automatically change WordPress to HTTPS?
No. Nginx must serve HTTPS correctly, and WordPress URLs and any old HTTP links may also need updating.

Will the certificate renew automatically?
That depends on the certificate provider and your server setup. Check the renewal process and confirm it updates the configured files and reloads Nginx when necessary.

Related

• Apple One: Best Entertainment Package?
• Disappeared Storage Tech: What Really Happened
• Audiophile Curse or Blessing? Honest Look