Tools that use RDAP for domain expiry

Rdap domain expiry monitoring belongs in the same product that already watches live TLS—registration lapse can invalidate certificates even when notAfter still looks healthy on the wire.

Platform owners shopping for consolidated expiry dashboards often discover their TLS monitor ignores registrar dates entirely. Others paste Whois screenshots into tickets that go stale the week registries redact fields. RDAP is the modern, structured replacement—but not every tool uses it honestly.

Procurement and SRE teams need one schedule that answers two questions: when does the certificate strangers see expire, and when does the domain name itself cease to exist? Spreadsheets that mix OpenSSL output with manual registrar logins do not scale past a dozen brands.

This guide evaluates rdap domain expiry monitoring capabilities: what RDAP actually returns, where registries omit dates, and how to pair registration watches with external handshake checks without duplicating noise.

What you are actually buying

A domain expiry feature is not generic Whois scraping. RDAP (Registration Data Access Protocol) returns JSON events—registration, last changed, and often expiration—from registry-authoritative servers. Good rdap domain expiry monitoring polls those records on a cadence aligned with TLS checks so both clocks appear beside each hostname you care about.

You are not buying a replacement for live certificate validation. RDAP does not tell you whether nginx reloaded after ACME or whether a CDN still serves an expired leaf. You are buying correlated timelines: the day TLS breaks on the wire and the day the name might stop resolving if billing fails.

Some TLDs and thick registries publish rich expiration events; others return sparse objects without expiration. A serious monitor surfaces unknown registration expiry instead of guessing from cached Whois. That honesty matters for ccTLDs and certain brand TLDs where RDAP lags policy changes.

Budget time to validate RDAP behavior on every TLD you operate—not only .com—before you trust a single dashboard for customer-facing SLAs.

Evaluation checklist

1. RDAP-first, not legacy Whois only. The product should query bootstrap-discovered RDAP servers, with clear labeling when it falls back or cannot parse expiry.
2. Pairing with live TLS. Domain and certificate expiry should share a hostname inventory so operators do not reconcile two spreadsheets.
3. TLD-tested transparency. Documentation or UI should explain when expiration is missing in RDAP for a given suffix.
4. Independent alert thresholds. Registration warnings at 30/14/7/1 days should not duplicate TLS alerts on the same day unless both are genuinely at risk.
5. Registrar vs registry clarity. For registrar-operated RDAP, confirm which entity’s date you are watching when reseller chains obscure billing contacts.
6. IDN and punycode handling. Internationalized domain names must query the A-label form RDAP expects.
7. Rate and cache discipline. RDAP servers throttle aggressive clients; monitors should cache responsibly without showing week-old expiration after a renew.
8. Audit trail. Each poll should store the fetched expiration event timestamp for post-incident review.
9. No false precision. Tools must not invent midnight UTC expiry when RDAP only returns year-month-day without timezone.
10. Hand-off commands. Useful products link to diagnostic flows like RDAP lookup for domain expiration when manual verification is needed.

Weight checklist items heavier for portfolios heavy in ccTLDs or transfer-heavy registrar accounts.

How ssldays fits

ssldays combines live TLS handshake inspection with RDAP registration queries on the same monitored hostnames. Certificate expiry reflects what the server presents—issuer, SANs, chain trust, and notAfter. Registration expiry comes from RDAP where published; when a TLD omits a reliable expiration event, the dashboard states that limitation rather than fabricating a date.

Alerts fire at 30, 14, 7, and 1 days for applicable signals, once per threshold per renewal cycle, via email on all plans. Starter and Pro add hourly TLS checks, higher domain caps (25 and 100), and webhooks for Slack and Discord when you want registrar risk in the same channel as certificate pages.

The free tier (three domains, daily checks) still helps solo operators prove RDAP coverage on their TLD mix before they pay for hourly correlation across a fleet.

Use ssldays free check for immediate TLS validation on any hostname; after signup, RDAP domain expiry monitoring runs beside scheduled certificate polls without a second product.

Common mistakes when choosing a monitor

Treating Whois redaction as RDAP failure. Some registries never exposed expiry in port-43 Whois; RDAP may still provide expiration events—test both paths per TLD.

Monitoring only TLS because “Certbot auto-renews.” Domain auto-renew can fail on expired corporate cards while certificates remain valid until the name is suspended.

Assuming one RDAP server per TLD worldwide. Bootstrap redirects and thick-registry models mean your tool must follow links, not hardcode hosts.

Ignoring transfer locks and pending deletes. RDAP status flags matter when expiration dates look fine but the name is in redemption.

Duplicate alerts for the same root cause. A lapsed domain and expired cert may page twice; tune routing so finance sees registrar risk and engineering sees presentation risk.

Copying registrar portal dates into tickets. Portal UI time zones differ from RDAP event timestamps; use the monitor’s stored event, not a screenshot.

Next steps

Inventory apex names by TLD and mark which registries you have never queried via RDAP. Walk through Whois expiration date alternatives for suffixes that frustrate manual lookup, then add hostnames to ssldays.

For each name, compare live TLS notAfter from free check against the registration expiration event your monitor captured. Gap analysis on three representative domains usually exposes whether rdap domain expiry monitoring is trustworthy for your program.

Expand to domain and SSL expiry monitoring in one place when you centralize customer brands under one on-call rotation.