Inspect certificate expiry
Before touching configuration, we will turn the symptom into a precise question and collect a baseline that can be compared after the work.Our specific objective is inspect certificate expiry. Monitor expiry…
Before touching configuration, we will turn the symptom into a precise question and collect a baseline that can be compared after the work.
Our specific objective is inspect certificate expiry. Monitor expiry from deployed certificates and test the full chain externally.
What you need before starting
Use a staging virtual host or direct loopback route, access to the active web-server configuration and an external client for final verification. Save the rendered configuration, identify every included file, and record the current certificate and upstream health. Test through the actual Host header and TLS server name.
Run the diagnostic in a controlled way
Start by printing the command rather than pasting it into an unidentified shell. Confirm every hostname, path and placeholder, then execute it from a session whose output you can preserve.
openssl x509 -in cert.pem -noout -dates- Check 1:
openssl x509 -in cert.pem -noout -dates. Run it without piping away errors and retain the complete output.
If the command contains &&, the shell runs the next check only after the previous one exits successfully. That protects the sequence from continuing on obviously invalid input, but it does not prove the result is operationally correct.
How to interpret what you see
Keep DNS, TLS, HTTP status, headers, cache behaviour, upstream timing and application content separate. The first failing boundary usually tells you which owner and log matter. For this task, keep returning to the original question: Monitor expiry from deployed certificates and test the full chain externally.
| Observation | Meaning | Next move |
|---|---|---|
| Expected output and exit status 0 | The diagnostic ran and returned a normal result. | Compare it with the baseline and continue to service-level verification. |
| Empty output | Possibly a healthy state, wrong scope, insufficient privilege or an overly narrow filter. | Confirm context and remove one filter at a time. |
| Permission or connection error | The observation path failed; it says nothing conclusive about the target service. | Fix access or test from an authorized vantage point. |
| Unexpected large result | The question may be too broad or the condition may be systemic. | Save evidence, narrow by time or component, and avoid impulsive bulk action. |
Verification that closes the loop
Validate syntax, reload rather than restart where supported, check local virtual-host routing, then test externally with headers and one representative application request. Record the before and after outputs alongside the exact time and revision. If a user-facing path exists, test it independently; do not substitute an internal status command for customer evidence.
Failure modes worth avoiding
Do not infer success from nginx -t alone: it validates configuration, not upstream health. Avoid broad WAF exclusions, permanent cache bypasses and certificate changes without chain verification.
The safest operator is not the one who never encounters failure. It is the one who preserves enough evidence to explain the failure and enough control to recover cleanly.
Rollback and handover
Put back the previous configuration or symlink, validate it, reload gracefully and confirm both the health endpoint and a real user route. Close the task with a short note containing the symptom, diagnostic output, decision, verification and any follow-up monitoring.
This guide follows the official reference linked below. Check the documentation for the exact version running in your environment because flags, defaults and output fields can change.
Primary source: Review the official reference ↗