SSL Certificate Checker - Issuer, SANs, Expiry, Chain JSON avatar

SSL Certificate Checker - Issuer, SANs, Expiry, Chain JSON

Pricing

from $0.64 / 1,000 certificate-checked hosts

Go to Apify Store
SSL Certificate Checker - Issuer, SANs, Expiry, Chain JSON

SSL Certificate Checker - Issuer, SANs, Expiry, Chain JSON

Live TLS handshake for up to 200 hosts per run: issuer, SANs, days-to-expiry, full chain walk, negotiated protocol, self-signed/expired diagnosis with exact error. $0.0008 per host, no start fee, unreachable hosts never charged — cheaper than measured incumbents ($0.001-$0.035).

Pricing

from $0.64 / 1,000 certificate-checked hosts

Rating

0.0

(0)

Developer

Broke to Built

Broke to Built

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

12 days ago

Last modified

Share

SSL Certificate Checker — Issuer, SANs, Expiry, Chain JSON

Everything about a host's live TLS certificate as clean JSON — issuer, SANs, days to expiry, full chain walk, negotiated protocol — for one host or up to 200 per run. Online, by API, or as an agent tool via Apify MCP.

This actor performs a real TLS handshake (SNI-aware, any port), reads the presented certificate even when validation fails (so you can diagnose self-signed and expired certs, not just detect them), and walks the issuer chain. Useful for expiry monitoring, migration verification, security audits, and inventorying certs across a host list.

What you get

  • valid / authorized / authorizationError — the handshake verdict and, when it fails, exactly why
  • issuer / subject / commonName / san — who issued it and what names it covers
  • validFrom / validTo / daysToExpiry / expired / notYetValid — the full expiry picture
  • selfSigned, serialNumber, fingerprint256, keyType / bits
  • protocol — negotiated TLS version (e.g. TLSv1.3)
  • chain / chainLength — every certificate up the issuer chain with its own validity window
  • Fail-soft: an unreachable host or refused connection never fails the run — it returns {ok: false, error} and is never charged.

Input

{ "hosts": ["github.com", "internal.example.com:8443"], "maxHosts": 50 }

Or a single host: { "host": "github.com" }. URLs are accepted; custom port supported.

Output (real run, trimmed)

{
"host": "github.com",
"port": 443,
"ok": true,
"valid": true,
"issuer": "CN=Sectigo Public Server Authentication CA DV E36, O=Sectigo Limited, C=GB",
"commonName": "github.com",
"validTo": "2026-09-30T23:59:59.000Z",
"daysToExpiry": 54,
"expired": false,
"selfSigned": false,
"keyType": "prime256v1",
"protocol": "TLSv1.3",
"chainLength": 3
}

Pricing

$0.0008 per host checked. No start fee. Unreachable hosts and connection failures are never charged — you pay only when a certificate was actually inspected.

Measured against store incumbents (2026-08-07): andok/ssl-certificate-monitor charges $0.001 per item, santamaria-automations $0.001 start + $0.001 per result, bgfc97 $0.003 per host, automation-lab $0.035 per start (19 users). A 100-host inventory here costs $0.08.

Honest limits

  • One certificate per host:port — the one presented for the SNI name you pass. Multi-cert setups (different certs per SNI) need one check per hostname, which is how the pricing works anyway.
  • valid reflects Node's CA bundle at run time; a cert chained to a niche private CA reports authorized: false with the exact authorizationError — inspect, then decide.
  • Certificate transparency logs, OCSP/revocation status, and cipher-suite enumeration are out of scope.

FAQ

Can it check non-HTTPS services? Yes — any TLS endpoint: mail.example.com:465 (SMTPS), db.example.com:5432 won't work (Postgres uses STARTTLS-style negotiation), but any direct-TLS port does. Default port is 443.

What do I get for an expired or self-signed cert? The full certificate details plus expired: true or selfSigned: true and the authorizationError — the actor reads certs that fail validation instead of erroring out, which is the whole point of diagnosing.

How do I monitor expiry across my fleet? Run your host list on a schedule and alert on daysToExpiry < 30. One 100-host sweep costs $0.08.

Why is the SAN list important? It is what the cert actually covers. A renewal that dropped a subdomain from the SANs breaks that subdomain silently — comparing SAN lists across runs catches it.

Why did some rows come back ok: false? Those hosts did not complete a TLS handshake (DNS failure, timeout, connection refused). Recorded with the exact error, never charged.

Use from code or AI agents

curl -s "https://api.apify.com/v2/acts/EliAI~ssl-certificate-checker/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
-X POST -H 'Content-Type: application/json' \
-d '{"hosts": ["yourdomain.com", "api.yourdomain.com"]}'

Agents: connect Apify MCP and call the EliAI/ssl-certificate-checker tool.

  • Capability: live TLS certificate inspection of one or many hosts — issuer, SANs, expiry, chain, protocol
  • Required input: host/url (string) or hosts/urls (array); optional port
  • Returns: one JSON record per host; valid + daysToExpiry summarize the verdict
  • Bounded: maxHosts caps the run; failures isolate per host
  • Side effects: none (a single TLS handshake per host, immediately closed)

For AI agents

This Actor is built to be called by software, not just by people.

  • Mount it directly as an MCP tool — no Store search, no ranking, just this one tool: https://mcp.apify.com/?actors=eliai/ssl-certificate-checker
  • Or call it over HTTP and get the results in the same request: POST https://api.apify.com/v2/acts/eliai~ssl-certificate-checker/run-sync-get-dataset-items
  • Pay with x402, without an Apify account. This Actor is whitelisted for agentic payments, so an agent holding USDC on Base can buy a prepaid token and spend it here. The minimum purchase is $1, the token balance is an absolute spending cap, and it expires 14 days after purchase.
  • Costs are predictable before you call. Pricing is pay-per-event (see Pricing above), so an agent can budget a run in advance instead of discovering the bill afterwards.
  • Send only the field you mean. If you pass the bulk field, it is used on its own; the single-value field is a fallback, never merged into your request. You are charged for the items you sent and nothing else.