Configuring Nginx with SSL Certificates from Let’s Encrypt

HTTPS protects traffic between a visitor and your Nginx web server. A certificate from Let’s Encrypt provides trusted encryption without the purchase and renewal process associated with many commercial certificate authorities.

On RHEL, CentOS Stream, and Fedora, Nginx commonly serves websites from /usr/share/nginx/html or a separate virtual host directory. The same configuration can support a personal site, an internal dashboard exposed through a reverse proxy, or a public .com.au domain.

The certificate request must use a domain name that resolves to the server’s public IP address. A browser accessing https://example.com must reach the same host where Certbot can complete its validation challenge.

This guide uses Certbot’s Nginx integration, firewalld, and systemd. It is suitable for an Australian VPS in Sydney, Melbourne, or Brisbane, and the commands also work for many lab servers connected through an NBN business connection.

Check DNS, Nginx, And Firewall Access

Create an A record for the hostname and point it to the server’s IPv4 address. If you use IPv6, create a correct AAAA record as well; an incorrect IPv6 entry can cause certificate validation to fail even when IPv4 is configured correctly. Check the result with:

dig +short example.com
dig +short www.example.com

Install and start Nginx, then permit web traffic through firewalld:

sudo dnf install -y nginx
sudo systemctl enable --now nginx

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Confirm that the site is reachable over plain HTTP before requesting a certificate. Australian domain registration and .au naming rules do not change Let’s Encrypt’s validation process, although the hostname must still be publicly resolvable.

Install Certbot And Prepare The Server

On Fedora, the required packages are usually available directly through DNF. On RHEL-compatible systems, enable EPEL first if the Certbot packages are not present in the configured repositories:

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-nginx

Check the installed versions and verify that Nginx’s configuration is valid:

certbot --version
sudo nginx -t

If your server hosts a PHP application or reverse proxy, make sure the relevant virtual host already includes the correct server_name. Certbot edits that server block, so a missing or inaccurate hostname can produce an incomplete HTTPS configuration. For broader Linux administration references, see these Linux administration guides.

Request And Apply The Certificate

Request a certificate for the root domain and its www alias. Replace the email address and domain names with values you control:

sudo certbot --nginx \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --no-eff-email \
  --redirect

The --nginx plugin identifies the matching server block, obtains the certificate, and updates Nginx. The --redirect option sends HTTP requests to HTTPS, which prevents visitors from accidentally using an unencrypted connection. Certbot normally stores the active files under /etc/letsencrypt/live/example.com/.

Test the result from the server:

sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com

A successful response should show an HTTP status such as 200, 301, or 302. Visit the site in a browser and inspect the certificate name, expiry date, and certificate chain.

Handle SELinux And Reverse Proxy Details

SELinux can prevent Nginx from reading certificate files or connecting to an upstream application. Keep SELinux enforcing, inspect denials before changing policy, and apply the correct boolean when Nginx proxies to a local service:

sudo setsebool -P httpd_can_network_connect 1

For application directories, label content with a web-readable context rather than disabling SELinux. The guide on managing SELinux contexts covers persistent labels and troubleshooting with restorecon.

If Nginx proxies to an app listening on 127.0.0.1:3000, keep the upstream private and expose only Nginx on ports 80 and 443. Confirm that the application generates secure URLs after the proxy is enabled, using headers such as X-Forwarded-Proto https when the framework requires them.

Test Renewal And Monitor Certificate Health

Let’s Encrypt certificates are short-lived, so automatic renewal is essential. Certbot usually installs a systemd timer. Inspect and test it with:

sudo systemctl list-timers 'certbot*'
sudo certbot renew --dry-run

The dry run performs a renewal simulation without replacing the live certificate. If it fails, check DNS, port 80 access, firewalld rules, and any reverse proxy or CDN in front of the host. A maintenance window in AEST or AEDT can be useful when supporting customers across Sydney, Perth, and Melbourne, because renewal tests and reloads are easier to correlate with local logs.

For a manual review, run:

sudo openssl s_client -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
  openssl x509 -noout -dates -issuer -subject

You can keep operational notes and recurring commands easy to find with Emacs bookmarks, especially when maintaining several Australian VPS instances.

After enabling HTTPS, verify that all application assets load over secure URLs and that HTTP redirects to the intended canonical hostname. Run sudo certbot renew --dry-run now, then record its successful output in your server maintenance log.