What defensive domain monitoring means in 2026
Monitoring SSL certificates and subdomains means continuously watching the public facts about a domain you own — its live TLS certificate, every certificate ever issued for it, the subdomains those certificates reveal, and the DNS posture underneath — so you find a forgotten host, an expiring certificate, or an unauthorized issuance before an attacker or an outage does. In 2026, the practical way to do this is a handful of API calls on a daily schedule against the public record.
That paragraph is the short answer. The rest of this page is for the security and platform engineers who have to actually run the monitoring. The framing throughout is defensive: you are watching domains you own or are explicitly authorized to assess, using only public data. No breach databases, no port scanning, no offensive tooling — just the certificate logs, DNS, and TLS handshakes that the whole internet can already read.
The problem you are actually trying to solve
Most organizations do not have a clean inventory of their own external attack surface. Domains accrete over years. A marketing team spins up promo.example.com for a campaign, requests a certificate, ships it, and forgets it. A staging host gets a real certificate and never gets torn down. An acquired company's subdomains quietly fold into yours. Each of those is a live certificate and a live hostname that nobody is watching.
The reader of this page usually wants three concrete outcomes. First, never be surprised by an expiring certificate — the kind of outage that takes down a checkout page at 2am and burns an on-call engineer's weekend. Second, know every subdomain that exists under your apex, including the ones no spreadsheet remembers. Third, get an early signal when a certificate is issued for your domain that you did not request, which is one of the clearest fingerprints of a misconfiguration or an impersonation attempt.
The good news is that all three signals are public. Certificate Transparency makes nearly every issued certificate observable. DNS is public by design. The TLS handshake is public to anyone who connects. The job is not to obtain secret data — it is to watch the public record consistently, on a schedule, so the signal reaches a human while it still matters.
Why Certificate Transparency is the backbone
Certificate Transparency is an append-only public log system that participating certificate authorities write to when they issue a certificate. It was built so that mis-issuance becomes detectable: if a CA issues a certificate for your domain, that fact lands in a public log whether or not you asked for it. For a defender, CT is a gift. It turns the question "what certificates exist for my domain?" from an unknowable into a query.
Two of the endpoints in this recipe lean on CT. /v1/intel/cert-transparency-history returns the deduplicated set of certificates ever issued for your domain or any subdomain, sorted newest-first. /v1/intel/subdomain-enumerate takes the same CT data and distills it into a clean list of hostnames by deduplicating the subject-alternative-name entries across every certificate. Both are passive: no DNS brute-forcing, no guessing, no paid feed — just reading the public log.
There is one honest caveat with CT-based enumeration. Because the log is historical, a hostname that appears in an old certificate may no longer resolve. CT tells you what was certified, not what is live right now. If you need a live-only view, pair the enumerated list with a resolver and drop the hosts that no longer answer. For attack-surface awareness, though, the historical list is often exactly what you want — a decommissioned host with a dangling DNS record is its own category of risk.
Where Ollagraph fits
You can build all of this yourself. CT logs are public, DNS is queryable, and openssl will hand you a certificate. The reason teams reach for an API is the same reason they reach for one anywhere else: they want the answer, not the plumbing. Ollagraph packages each of these checks behind a single bearer token and a one-line request body, returns canonical JSON, and bills one credit per call with auto-refund on failure.
The seven endpoints below are the defensive intelligence surface for a domain. They all take a single domain field (two accept an optional second parameter), they all run on free public data, and they all return structured JSON you can diff against yesterday's snapshot. Strung together on a daily schedule, they are a complete external-posture monitor for the assets you own. For the broader picture of what the intelligence surface covers, see the intelligence overview and the security and intel use cases.
The recipe, step by step
Seven calls, real curl, real request shapes. Every body is a single JSON object with a domain key. Run them against a domain you own and you have a posture snapshot in under five minutes.
Step 1. Get an API key
Sign up on the pricing page, grab a key from the dashboard, and export it for the session. Every call authenticates with the same bearer token.
export OLLAGRAPH_API_KEY="osk_xxxxxxxxxxxx"Step 2. Check the live certificate
Start with the certificate the domain is serving right now. /v1/intel/ssl performs the TLS handshake and returns the live certificate details — the validity window, the issuer, the subject, and the chain. This is the call you poll daily so an expiry never surprises you.
curl -X POST https://api.ollagraph.com/v1/intel/ssl \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'Wire the validity window into a threshold check on your side — alert at 30 days, escalate at 7 — and the renewal calendar takes care of itself. The exact response fields are documented in the live spec; treat the validity dates and issuer as the load-bearing ones for monitoring.
Step 3. Pull the certificate-transparency history
Now widen the lens from the live certificate to every certificate ever issued. /v1/intel/cert-transparency-history reads the public CT logs and returns a deduplicated, newest-first list of certificates for your domain and its subdomains. A certificate you don't recognize at the top of the list is the signal you came for.
curl -X POST https://api.ollagraph.com/v1/intel/cert-transparency-history \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'Each certificate entry carries the hostnames it covers in its dns_names list, which is what makes CT history doubly useful — it is both your issuance record and your first draft of a subdomain inventory. Snapshot the result daily and diff it; a new entry that appeared overnight is worth a human glance.
Step 4. Enumerate the subdomains
When you want the hostname inventory specifically, rather than the raw certificate list, use /v1/intel/subdomain-enumerate. It pulls the same CT data and returns the deduplicated SAN list as a clean set of hostnames — your attack surface, as recorded by the certificate logs.
curl -X POST https://api.ollagraph.com/v1/intel/subdomain-enumerate \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com",
"max_results": 500
}'The optional max_results field caps the return; most organizations fit comfortably under the default of 500, and very large estates can raise it. Remember the historical caveat from earlier: this is what was certified, not what currently resolves. Feed the list into a resolver if you need a live-only view, or keep the full list if dangling records are part of what you are hunting.
Step 5. Confirm DNS is consistent everywhere
A certificate is only as good as the DNS pointing at it. /v1/intel/dns-propagation queries the same record across multiple public resolvers and shows whether they agree — which catches a half-finished migration, a stale record on one resolver, or a propagation lag before your users hit it.
curl -X POST https://api.ollagraph.com/v1/intel/dns-propagation \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com",
"record_type": "A"
}'The optional record_type field defaults to A and also accepts AAAA, MX, TXT, NS, CNAME, and SOA. Run it for the record types that matter to your service and alert when the resolvers disagree.
Step 6. Audit who is allowed to issue certificates
CAA records are your standing instruction to the certificate authorities of the world about who may issue for you. /v1/intel/caa returns your current CAA posture: which CAs may issue, which may issue wildcards, and where incidents should be reported.
curl -X POST https://api.ollagraph.com/v1/intel/caa \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'The absence of any CAA record is itself a finding: it means the open default applies and any CA may issue for your domain. Pairing a tight CAA policy with the CT monitoring from Step 3 gives you both a fence and a tripwire — CAA narrows who can issue, and CT tells you if someone did anyway.
Step 7. Check DNSSEC and nameserver resilience
Two final posture checks round out the sweep. /v1/intel/dnssec reports the three discrete DNSSEC observations — whether you publish DNSKEY records, whether the parent zone has delegated a DS record, and whether a fresh resolver set the authenticated-data bit — rather than collapsing a genuinely multi-dimensional state into one misleading pass/fail.
curl -X POST https://api.ollagraph.com/v1/intel/dnssec \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'Then /v1/intel/nameservers returns your authoritative nameservers and the IPv4/IPv6 each one resolves to, plus a diversified boolean. When that flag is false, every nameserver sits in the same network block — a single-provider configuration that becomes a single point of failure the day that provider has a bad afternoon.
curl -X POST https://api.ollagraph.com/v1/intel/nameservers \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "example.com"
}'Stitching it into a daily monitor
The seven calls above are the raw material. The product is what you build on top of them: a scheduled job that runs the sweep once a day, stores each response with a timestamp, and diffs against the previous run. The diff is where the value lives. A new certificate in the CT history, a subdomain that wasn't in yesterday's enumeration, an SSL validity window that crossed your 30-day threshold, a resolver that fell out of agreement — each of those is an event your job can turn into an alert.
Keep the architecture boring. Land each raw JSON response in a column rather than over-normalizing on the first pass, so you can re-derive new alerts later without re-querying. Key your storage on (domain, endpoint, captured_at) and you have a clean history table you can chart and audit. Because every call is one credit with auto-refund on failure, the whole daily sweep for a single domain costs a handful of credits — cheap enough to run across every domain in your estate without a budget conversation.
A realistic scenario
Consider a platform-security engineer at a company with roughly forty external domains accumulated across a decade and two acquisitions. There is no authoritative inventory; the closest thing is a spreadsheet last updated eighteen months ago. The CISO wants a monthly attack-surface report and an alert the moment a certificate is issued that nobody requested.
The engineer wires the seven-call sweep into a nightly job, one pass per apex domain. On the first run, the subdomain enumeration surfaces nineteen hostnames that weren't on the spreadsheet — three of them staging environments with live certificates and no owner. The CT history flags a certificate issued the prior week for a marketing subdomain the security team had never heard of, which turns out to be a legitimate-but-unannounced campaign launch. The nameserver check returns diversified: false for two of the acquired domains, both still on a single provider. None of this required a single packet of offensive traffic — it all came out of the public record, read consistently for the first time.
Within a week the engineer has a diff-based alerting pipeline and a living inventory. The monthly report writes itself from the stored snapshots, and the unauthorized-issuance tripwire the CISO asked for is just the CT-history diff with a notification on the end.
Staying defensive and in scope
One principle keeps this work clean: only monitor domains you own or are explicitly authorized to assess. Everything in this recipe reads public data, but the intent matters. Running a daily posture sweep on your own estate, or on a client's estate under a written engagement, is textbook defensive security. Pointing the same tools at infrastructure you have no relationship with is a different activity with a different risk profile, and it is not what this surface is for.
Ollagraph's intelligence endpoints are deliberately built around this boundary. There is no port scanning, no breach-database lookup, no paid threat-intel feed, and no mass-enumeration tooling anywhere in the surface — only observations of the public infrastructure record. That constraint is a feature: it keeps the product on the defensive side of the line and keeps your usage easy to justify to a security review.
Pairing it with the rest of the stack
Domain monitoring rarely lives alone. Teams routinely pair this sweep with domain enrichment when they want context on an unfamiliar host that turned up in the CT logs, and they lean on the wider capabilities surface when an investigation needs page-level fetches alongside the infrastructure facts. Browse the full recipe library for adjacent playbooks, and read the blog for deeper write-ups on web-data and security workflows.
What to do next
Sign up for a key, pick one domain you own, and run the Step 2 SSL call to confirm the pipeline works end to end. Then wrap the seven calls in a nightly job, store each response, and add a diff. Most teams have a working internal monitor inside a day and a production attack-surface dashboard inside a week.
Read the docs for the full response shapes, confirm the request fields against the live spec, and ship the sweep.