$ Linux One Liners
Back to problems

problem hub

Read-only first

Nginx serving the wrong SSL certificate

Inspect the live certificate, Nginx server block, Certbot inventory, and DNS before reissuing or reloading TLS config.

Safest first command

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

Before you run this

Expected output: Subject, issuer, and validity dates for the certificate currently served to that hostname.

When not to use it: Do not paste certificate or host details publicly without redacting internal names.

Expected output example

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Jul  1 00:00:00 2026 GMT
notAfter=Sep 29 23:59:59 2026 GMT

How to read the result

The hostname must appear in the served certificate SANs and the active Nginx server block must point at the intended certificate files.

What to check next

Subject/SAN does not include hostname

Means: The server is presenting a certificate for another name.

Next step: Read the served SANs and Nginx SSL certificate directives.

Show Served Certificate SANs

Nginx config points at an old path

Means: The wrong server block or certificate file may be active.

Next step: Map ssl_certificate and server_name directives.

Find Nginx SSL Certificate Directives

Certbot inventory has the correct certificate

Means: Renewal may be fine; Nginx may not be using that lineage.

Next step: List Certbot certificate inventory.

Inspect Certbot Certificate Inventory

TLS decision tree

Separate the certificate served over the network from certificate files on disk. The live endpoint is the source of truth for what users see.

  1. openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
  2. openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
  3. grep -RInE 'ssl_certificate|ssl_certificate_key|server_name' /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null
  4. sudo certbot certificates

Bad fixes to avoid

Do not reissue certificates blindly, edit every server block, or reload Nginx before proving which certificate is live and which config owns the hostname.

Common causes

  • Wrong default_server block handles the hostname.
  • Nginx points at an old certificate lineage.
  • DNS reaches a different server than expected.
  • Certificate renewed but Nginx was not reloaded after a safe config test.

What not to change yet

  • Do not delete certificate files.
  • Do not reload Nginx before nginx -t.
  • Do not change DNS until the live certificate path is understood.

Stop and escalate if

  • The next step could interrupt users, remove data, or lock out access.
  • The output includes secrets, customer data, or private infrastructure details.
  • You cannot explain the blast radius of the repair command.

supporting commands

Command path

Guides and drills