SSL Certificate Expiry Checker and Reminder Calendar
Enter a domain, certificate, or notAfter date; see days remaining; and create reminders for Google Calendar, Outlook, or Apple Calendar.
Certificate imports and date calculations stay in your browser. Live domain checks send the public hostname and port to the disclosed TLS inspection service.
Check a certificate
Advanced renewal settings
Filled from the hostname or certificate CN when available.
Planning templates (starting points, not universal rules)
Certificate result
No certificate checked yet
Enter a hostname, import a certificate, or supply a timezone-qualified expiry date.
Import: Google Calendar: Settings → Import & export. Outlook: Add calendar → Upload from file. Apple Calendar: File → Import. A downloaded ICS is a static snapshot; it does not detect a renewed certificate or update itself.
Advertisement
Bulk certificate inventory
Enter up to 25 public hostnames, single-line notAfter=… GMT records, one-line base64 DER certificates, or PEM certificate blocks; add an owner after a hostname and comma. CSV columns can include hostname, port, owner, expiry, or a base64 certificate.
Select
Next action
Advertisement
How to check an SSL certificate and create reminders
Choose a source: check a public hostname, import a local PEM/CRT certificate, paste OpenSSL output, or enter an absolute notAfter time.
Confirm the endpoint: a live result states the requested and final hostname so a redirect cannot silently change what was inspected.
Read the recommendation: compare today with the renewal, issue, deploy, validation, and expiry milestones.
Adjust only if needed: owner, environment, planning template, offsets, timezone, and ICS strategy are under Advanced renewal settings.
Export a snapshot: use a direct calendar link, an ICS file, or CSV. Continue monitoring the deployed endpoint after renewal.
Date model and timezone rules
The certificate’s notAfter is stored as one absolute instant. Results always show UTC plus the selected display timezone. Manual input is rejected if it omits Z, UTC, GMT, or a numeric ISO 8601 offset.
Renewal start:notAfter − renewal window × 86,400,000 ms
Issue/deploy/validate by:notAfter − each lead × 86,400,000 ms
Alert date:notAfter − alert offset × 86,400,000 ms
Days remaining:(notAfter − now) ÷ 86,400,000, rounded up for the headline. Offsets are exact 24-hour intervals, not local calendar-date subtraction, so a daylight-saving transition does not change the elapsed interval.
X.509 validity runs through notAfter inclusively, but clients can reject the certificate immediately after that instant. Calendar all-day events use an exclusive next-day DTEND.
Renewal planning templates
These operational templates are starting points. Use your CA’s policy, deployment risk, and change lead time; an ACME client that supports ACME Renewal Information (RFC 9773) should prefer the CA-provided suggested renewal window.
Template
Start / issue / deploy / validate
Use it as
Automated ACME
30 / 10 / 3 / 1 days before expiry
A human backstop for failed automation; use ARI when the CA supplies it.
Manual validation
60 / 21 / 7 / 2 days
A baseline where approvals, validation evidence, or change windows add latency.
Internal PKI
45 / 14 / 5 / 2 days
A baseline that includes trust-store rollout and dependent-service restarts.
Short-lived public TLS
14 / 7 / 2 / 1 days
A tight automation-focused plan, not a substitute for continuous monitoring.
Source:notAfter=Oct 14 12:00:00 2026 GMT. Current instant: 16 July 2026 12:00 UTC. Days remaining: (14 Oct − 16 Jul) = 90 days.
Template substitution: renewal 14 Oct − 30d = 14 Sep; issue −10d = 4 Oct; deploy −3d = 11 Oct; validate −1d = 13 Oct, all at 12:00 UTC.
Alerts: 14 Sep (30d), 30 Sep (14d), 7 Oct (7d), 11 Oct (3d), and 13 Oct (1d). Recommendation: automation may continue now; investigate if the certificate has not renewed when the 30-day window opens.
Calendar result: expiry-with-alarms creates one 14 October event with five VALARM reminders; milestone mode creates Today, renewal-start, issue-by, deploy-by, validate-by, and expiry entries.
Manually renewed certificate
Source:2026-12-31T23:59:59Z. Current instant: 16 July 2026 12:00 UTC. Exact time remaining is about 168.5 days; the headline rounds up to 169 days.
Alerts: 1 Nov (60d), 16 Nov (45d), 1 Dec (30d), 17 Dec (14d), 24 Dec (7d), 28 Dec (3d), and 30 Dec (1d). Recommendation: assign the owner and approval path before 1 November, especially because year-end change freezes may remove deployment days.
Calendar result: milestone mode produces separate renewal, issue, deploy, validation, and expiry events suitable for assigning operational work.
Why certificate expiry calendars matter
TLS certificate expiry is a simple date problem until ownership, DNS validation, load balancer bindings,
maintenance windows, and deployment checks are spread across teams. A calendar schedule gives owners multiple
chances to notice failed automation before users see browser errors or service clients reject a connection.
Treat the calendar as one layer. Production systems should also have automated monitoring for certificate
chain validity, hostname coverage, remaining lifetime, issuer changes, and deployment status on every endpoint
that terminates TLS.
Methodology
Editorial owner and reviewer: Starlight Robotics Infrastructure Editorial Team Last reviewed and modified: 16 July 2026 Software version: 2.0
Calculation test summary: exact 24-hour subtraction was checked across spring-forward and fall-back DST boundaries; UTC/GMT and ISO-offset parsing were compared at the millisecond level; all-day DTEND was checked as exclusive; ICS uses CRLF, stable UIDs, escaped values, and UTF-8 byte-aware 75-octet folding; PEM parser fixtures cover CN, issuer, serial, validity, and DNS SANs.
Limitations: the local parser reads the first PEM certificate and selected common X.509 fields; it does not validate signatures, trust, revocation, private-key matches, or the full chain. A live check is observed by a third-party server from its network location, may be cached for 60 seconds, blocks private addresses, and cannot prove every CDN edge serves the same certificate. Calendar exports never monitor renewal.
FAQs
How do I find an SSL expiry date in Chrome or Firefox?
In Chrome, open the site controls beside the address, choose the secure connection/certificate entry, then inspect “Valid to.” In Firefox, select the padlock → Connection secure → More Information → View Certificate. Browser wording varies by version; confirm the exact notAfter time and timezone.
How do I check with OpenSSL?
Run openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltName. -servername sends SNI so virtual hosts return the intended certificate. See the OpenSSL x509 documentation.
Is notAfter UTC?
In X.509 it is encoded as UTCTime or GeneralizedTime, normally with Z for UTC. OpenSSL commonly prints GMT. This tool treats it as an absolute instant and rejects ambiguous manual local times.
What happens when a certificate expires?
After notAfter, conforming clients can fail certificate path validation and block or warn on the TLS connection. Existing sessions and client behavior vary, so do not treat the expiry instant as usable deployment time.
When should I renew a 90-day certificate?
Let the ACME client follow the CA’s ARI window when supported. Otherwise, a 30-day operational window is a common starting point, with monitoring that escalates if automation has not produced and deployed a replacement.
Why does a renewed certificate still look old?
The new certificate may exist at the CA but not on the TLS terminator, a load balancer listener may still reference the old secret, a CDN edge may be stale, or DNS may send the check to a different endpoint. Recheck each hostname, port, region, and termination layer.
How should wildcard and SAN certificates be tracked?
Track the certificate object and every endpoint that deploys it. A wildcard covers only one label at its wildcard position, and SAN entries define hostname coverage. One renewal can still require updates on many load balancers or clusters.
Do downloaded calendar reminders update automatically?
No. ICS downloads and direct event links are static snapshots. Regenerate them after renewal or planning changes, and use active certificate monitoring for current state.
How do I handle private hosts or non-443 ports?
Enter another implicit-TLS port for a public host. Private, loopback, and link-local targets are blocked by the live API; run OpenSSL inside the relevant network and paste its output, or import the certificate locally.
Does “follow redirects” inspect every certificate?
No. It follows the HTTPS URL chain and inspects the final hostname. The result states both endpoints. Disable it to inspect only the originally requested TLS endpoint.
Disclaimer
This is an infrastructure planning aid. Verify certificate validity, chain, hostname coverage, revocation
state, DNS validation, deployment bindings, monitoring, and organizational change requirements before relying
on a renewal plan.
Starlight Tools