CertNotify Community
The scanning engine is open source
Every check CertNotify runs against the public internet lives in a AGPL-3.0-licensed package you can read, run and self-host. No account, no API key, no telemetry, no phone-home.
Why this is open
Security tooling asks for a lot of trust. Before you point a scanner at your infrastructure, it is reasonable to want to know what it actually does — which hosts it contacts, what it does with the results, and whether it quietly reports your attack surface back to a vendor. That is not a question a marketing page can answer credibly. It is a question source code answers.
So the engine is open. You can read every network call. You can confirm there is no telemetry, because you can grep for it. You can run it in an air-gapped environment, in CI, or against a host you would never let a SaaS product near.
The licence is AGPL-3.0, chosen deliberately. You can use it, modify it and self-host it freely, including commercially. What you cannot do is take the engine, close it, and resell it as a competing hosted service without publishing your changes. That is the trade that lets the scanners stay open permanently rather than until it becomes commercially inconvenient.
14 checks, all of them real
Every check uses Node built-ins or free, keyless public services — RDAP registries, Cloudflare DNS-over-HTTPS, Certificate Transparency logs, public DNSBL zones. Nothing here is a demo, a simulation, or a teaser for the paid tier.
Stateless — run anywhere, no history needed
| ssl | TLS handshake, certificate validity and expiry, issuer, TLS version and grade |
| whois | Domain registration status and expiry, via public RDAP |
| dns | A, AAAA, MX, TXT, NS, CNAME, SOA and PTR records |
| dnssec | DNSSEC signing and validation, via DNS-over-HTTPS |
| SPF, DKIM and DMARC posture — including duplicate SPF records, which fail SPF outright | |
| headers | Ten HTTP security headers, graded on quality rather than mere presence |
| ports | TCP-connect probe against 15 well-known ports |
| blacklist | Your domain's IP against seven public DNSBL feeds |
| uptime | HTTPS with HTTP fallback — status, response time, redirects |
Stateful — compared against your last run
These keep a baseline in a plain JSON file under ~/.certnotify/state. No database, no account, nothing leaves your machine.
| dns-monitor | Diffs DNS records against your last run — flags possible hijacking |
| defacement | Fingerprints the homepage and flags any change since the last run |
| whois-privacy | Detects registrant privacy protection being switched off |
| mixed-content | HTTP resources embedded in HTTPS pages |
| subdomains | Certificate Transparency logs plus a DNS probe, tracking what is new |
Four ways to run it
CLI
npx certnotify scan example.com
No install required.
Library
import { scan } from 'certnotify'Every scanner exported individually.
Docker
docker run --rm certnotify scan example.com
Non-root, with a volume for baselines.
GitHub Action
uses: siddhantmallah/certnotify-community@main
Fail a build below a score threshold.
What is open, and what is not
The scanners are open and stay open. What the hosted product sells is running them continuously, remembering the results, correlating them across your estate, and telling the right person when something changes.
| Capability | Community | Cloud |
|---|---|---|
| All 14 security checks | ||
| CLI, library, Docker image, GitHub Action | ||
| Self-hosting, unlimited targets | ||
| Local scan history on your own disk | ||
| Scans run for you on a schedule | ||
| Historical trends across months | ||
| Email and WhatsApp alerting | ||
| Teams, roles and shared dashboards | ||
| Correlation across findings and assets | ||
| Compliance framework mapping |
One nuance the table flattens: the Community edition does have monitoring, in the sense that dns-monitor and defacement compare against your previous run. The difference is who runs it. Self-hosted, you schedule it and store the baselines. On Cloud, it runs whether or not you remember to.
Contributing
Issues and pull requests are welcome. A false positive or false negative is the most useful bug report the project can receive — there is an issue template for exactly that, and a security policy for anything exploitable in the scanner itself.
Want the same checks run for you on a schedule, with history and alerting? See CertNotify Cloud pricing — there is a free tier.