tech.ssl-expiry-check·version 1.0.0·draft
Check certificates before they expire
Every HTTPS endpoint the company runs has a certificate that is valid, matches its names, chains correctly, and is being renewed — anything else is a task with a deadline.
When to use
Every week, for every domain and hostname the company serves over HTTPS. Not when a site is already down or throwing certificate errors in a browser — that is an incident, use tech.website-down. Not for the domain name itself expiring — that is tech.renew-domain, which this check must not overlap with (a valid certificate on a lapsed domain is still a red row).
Before you start
- The domain list is current: every domain in the registrar list appears here, including defensive and
- The hostname map exists: for each domain, which names are expected to answer with a certificate
- It is known which certificates are automatic (ACME/Let's Encrypt) and which were bought and must be
The trail7 steps
Collect the targetsagent
Read the domain list and the hostname map; resolve each hostname to confirm it still points at our infrastructure.
Done when the run has a list of hostnames to check, each marked expected / unexpected.
Read each certificate from the outsideagent
For every hostname, fetch the certificate a visitor actually receives: issuer, notBefore, notAfter, subject and SANs.
Done when every hostname has an expiry date and days remaining in the table.
⛔ Never read the expiry from the renewal system's own records — read what the server serves.
Verify the certificate fits the name and the chainagent
Check the hostname is covered by the SANs, the chain validates from outside (no missing intermediate), and the certificate is not self-signed or for a neighbouring name.
Done when each hostname is marked fit / misnamed / broken chain.
Verify renewal is actually happeningagent
For automatic certificates, compare notBefore with today: a Let's Encrypt certificate renewed within the last ~90 days means the job works; an old notBefore with a far expiry means it was bought once and nothing renews it. For bought certificates, confirm the renewal date is in the watch (
ops.contract-renewal-watchor the domain list).Done when each certificate is marked auto-renewing / manual / orphaned.
Check the endpoints behind the certificateagent
Open each HTTPS endpoint; confirm it answers, redirects http→https where expected, and the certificate the browser sees matches S2.
Done when each hostname is marked serving / stale cert / not answering.
⛔ A certificate renewed on disk but not reloaded is the classic false pass — S5 catches it.
Flag and open tasksagent
Every red row (under 30 days, misnamed, broken chain, orphaned, not answering) gets a task in the tasks module with the hostname, the finding, and a deadline before the expiry date.
Done when every red row has a task id next to it.
Reportagent
Send the owner the weekly summary: how many hostnames checked, how many red, the earliest expiry, and the task ids opened.
Done when the report is sent and the dated table is stored as evidence.
Checks — how we know it worked
- Every hostname on the map appears in the table — a missing row is a miss, not a pass.
- Every certificate has 30 days or more remaining, or has a task with a deadline before expiry.
- Every automatic certificate shows a recent notBefore — renewal proven, not assumed.
- Every hostname answers with the same certificate S2 recorded (ask the server, not the renewal tool).
If it goes wrong
| Symptom | Response |
|---|---|
| Automatic certificate under 30 days, notBefore old | The renewal job is broken: check the ACME account contact still receives mail, re-run the renewal by hand once, open a task with the outcome. |
| Server serves an older certificate than issued | The service was not reloaded after renewal — reload it, re-check from outside in S5, note the service in the task so it is watched next run. |
| Hostname answers but is not on the map | A leftover or someone's new subdomain — record who it belongs to, ask the owner whether to keep, monitor or remove it. |
| Certificate expired, site showing errors | Stop checking, escalate as an incident — hand to tech.website-down; this playbook records the failure, it does not fight the fire. |
| Chain validates locally but not from outside | Missing intermediate on the server — install the full chain, re-run S3 from a public resolver-side check. |
What each step leaves behind
- S1the run has a list of hostnames to check, each marked expected / unexpected.
- S2every hostname has an expiry date and days remaining in the table.
- S3each hostname is marked fit / misnamed / broken chain.
- S4each certificate is marked auto-renewing / manual / orphaned.
- S5each hostname is marked serving / stale cert / not answering.
- S6every red row has a task id next to it.
- S7the report is sent and the dated table is stored as evidence.
Evidence to keep
The dated expiry table for the run · task ids opened and their deadlines · the weekly report as sent · for any red row, the raw certificate details (issuer, SANs, notAfter) captured at check time.
How this playbook improves
After every 10 runs ask: how many red rows, and did any certificate reach under 30 days twice — meaning the fix did not hold? Were there false alarms (a red row that was fine)? Did any hostname on the map disappear, or any serving hostname stay off the map? Did any certificate expire with no warning despite this check running? A new version changes the step that missed it, and says so in its change note.
Obligātās sīkdatnes tur sarunu kopā. Analītika ir izslēgta, līdz tu atļauj — tā neliek nevienu sīkdatni un neglabā ierīces identifikatoru.Necessary storage keeps your conversation together. Analytics is off until you allow it — it sets no cookie and stores no device identifier. Ko mēs glabājamWhat we store