How often have you looked at an SSL certificate and cared about nothing beyond the Common Name, the DNS names, and the issue/expiry dates? A certificate says far more than that. It carries stories and motives - which companies are spinning up new domains and subdomains, who just revoked a certificate, why a firm switched Certificate Authorities. SSL has always been praised for its cryptographic strength but criticised for a weak issuance process that leans entirely on CAs (which are, after all, businesses). Yet few people ever explore certificates in real time. There are search engines for this, but none as comprehensive, fast, and free as CertDB.
Certificate Authorities have been attacked1 by hacking groups2, and in some cases implicated3 directly. The industry’s response - browsers and vendors monitoring certificates through transparency logs4, nudging users toward safer behaviour5, and revoking the bad ones - has been genuinely valuable, yet pentesters still rarely find much to work with during an assessment. More recently, the business interests of CAs around issuance have drawn real criticism, with some being distrusted outright6 for not doing the job well. Meanwhile organisations are moving aggressively to HTTPS, helped along by Let’s Encrypt wildcard certificates. What’s been missing is a single platform to pull all of this together - to analyse certificates, map an organisation’s SSL footprint, and turn it into intelligence.
That’s where CertDB comes in - a well-built project, maintained by sharp people, and free forever7 for the public. I’ve spent the last few weeks putting it through its paces, and the short verdict is: it’s excellent. A few quirks, but highly recommended.
crt.sh and CertDB serve different goals. crt.sh draws from the Certificate Transparency (CT) logs, where “legit” CAs submit certificates in near real time. CertDB instead scans the IPv4 space and domains directly, finding and analysing certificates - good or bad.
CertDB can also surface self-signed certificates, which crt.sh cannot. So CertDB gives a more realistic view of HTTPS in the wild - which IP is using what, self-signed, invalid CA, and so on - while crt.sh shows the tidy, law-abiding view.
What it is#
CertDB is an internet-wide search engine for SSL certificates. In plain terms, it parses each certificate and makes its fields indexable, so you can query them. The common fields it indexes:
| Field | Details |
|---|---|
| Subject | Country, State, Category, Serial Number, Locality, Organization, Common Name |
| Issuer | Country, State, Locality, Organization, Common Name |
| Others | Public Key IP Address related to the domain, Validity Dates |
| Fingerprint | SHA1, SHA256 and MD5 |
| Extensions | Usage, Subject Key ID, Authority Key ID, ALT Names, Certificate Policies |
Once these fields are extracted, you can query them individually or combine them into more complex logical queries. CertDB also offers the raw certificate, the public key, and JSON-formatted certificate data for download. They’ve since integrated Alexa rankings with domains and IPs, and surface curated lists - top domains, organizations, countries, issuers, and more.
One especially handy list is expiring certificates: the domains and organizations whose certificates are about to lapse - useful when auditing or assessing a firm’s digital footprint.
Real-time coverage#
The documentation says CertDB continuously scans every reachable web server on the internet, though my own tests weren’t conclusive on that. I’ve asked the team to clarify and will share their answer in a follow-up interview. Either way, once their scanner picks up a certificate, the data is available publicly for analysis in near real time.
Use cases#
With all this data extracted, the point is to filter it down - through the GUI or the API. The GUI is open to everyone via the search box; the API needs a free account.
Register at certdb.com/signup and you’ll be issued an API key good for 1,000 queries a day, up to 1,000 results each.
| Field | Value |
|---|---|
| URL | https://certdb.net/api |
| Method | GET, POST |
| api_key | |
| q | Any query (just like in search interface) |
| response_type | 0 - JSON list of the dictionary with found certificates with all details 1 - JSON list of found certificates in base64 2 - JSON list of distinct organizations from found certificates 3 - JSON list of distinct domains from found certificates |
Registration takes about 30 seconds. A few example queries:
- GoDaddy-issued certificates for Italian domains -
issuer:"Godaddy.com" country:"Italy" - Certificates within a subnet or IP range, e.g. an Amazon global range8 -
cidr:"13.32.0.0/15" - Certificates expiring in the next ten days -
expiring:"10 days" - Netflix certificates expiring in the next seven days -
expiring:"7 days" organization:"Netflix" - New Safeway Insurance certificates from the last five days, via API -
new:"5 days" organization:"Safeway Insurance Company"
There are plenty of angles here - past certificates issued to a firm, or a newly registered domain hinting at a new business line. A couple I reach for during an assessment:
- Enumerate subdomains - dork
site:example.com, then iterate (site:example.com -www, then-www -test, and so on) or use a threat-intel tool - and check whether each has a valid SSL certificate. Flag anything still not on HTTPS (Google is increasingly unforgiving about that). - Assess a company by its domains and organization -
organization:"Example Inc."- and you’ll often be surprised: firms lose track of domains registered in their name, or certificates they issued and never renewed.
Quirks#
Great as it is, there are rough edges the team is working on:
- Error handling isn’t polished - a malformed API query dumps a lot of debug data that ought to be cleaned up.
- API keys can’t be regenerated or revoked yourself; you have to contact CertDB support.
- The API key can be passed in a
GETrequest, which isn’t ideal - it can be cached at intermediate hops like proxies. - The documentation is thin, especially for the API.
- There are no worked API examples. CertDB would benefit from a page showing calls in Python, cURL, Ruby, Perl, and the like, including how to parse the JSON results.
Verdict#
After a few weeks with it, my honest take is that CertDB has real potential and practical value. I’ve used it while assessing AWS instances and Fortune 500 firms, and I’ve caught expiring certificates for clients and flagged them in time. I’d strongly recommend giving it a look and registering an account. You could even wire up a cron job to watch the dates and SSL footprint of an organization.
Next up: I’ll soon be publishing an interview with the team, digging into their roadmap, competition, and what’s next.
https://arstechnica.com/information-technology/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack/?source=cybersins ↩︎
https://arstechnica.com/information-technology/2011/08/earlier-this-year-an-iranian/?source=cybersins ↩︎
https://arstechnica.com/information-technology/2018/03/23000-https-certificates-axed-after-ceo-e-mails-private-keys/?source=cybersins ↩︎
https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html?source=cybersins ↩︎
https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html?source=cybersins ↩︎
/spyse-exclusive-interview-with-cybersins-free-security-tools/, CertDB confirms this project will always be free to use. ↩︎