Is TLSInventory right for me?
Since our release the TLS monitoring has become standard and many other projects are better suited for some specific use-cases:
- System administrator (warning about upcoming certificate expiration) - e.g. Uptime Kuma
- Detailed TLS monitoring with output to JSON (including “grade”) - SSLyze (since version 5.0)
We still have some unique features
- Extremely efficient data storage for large volume of scans
- Scanning 1 million domains using SSLyze takes ~250 GB, TLSInventory deduplicates that data to ~50 GB
- Running the same scan twice, SSLyze would have ~500 GB, TLSInventory ~50.7 GB.
- Data can be queried using SQL!
If you’re a researcher and want to monitor in-detail and long-term the TLS trends, having deduplication is essentially necessary.
Outages from expired certificates are common occurrence on today’s internet. Wouldn’t it be better to do prevent them, instead of fixing them only after your regular uptime monitoring sounds the alarm? This open-source project can help you prevent such outages.
But it’s more than just an certificate expiration monitoring. It also allows you to monitor how secure is your HTTPS configuration, if any new subdomains appeared for your domains, what certificates are used where, and more.
Why not just use SSLabs?
SSLabs is incredibly useful, but not a great fit if you need to:
- scan services that are in internal network (i.e. not on internet)
- scan a server running on specific IP (for specific hostname), that’s not yet propagated through DNS (for example a stage server)
- scan many different domains (scanning is rate limited)
- scan regularly as part of monitoring (and get notifications before problems like certificate expiration occur)
TLSInventory can help you with all of the above - either directly using the publicly available instance, or you can self-host the app.
This whole project is open-source with MIT license. It’s comprised of multiple parts:
- Backend - where most of the magic happens - API, scanning, database
- Frontend - web interface which consumes the API provided by backend.
and multiple few utilities, which are all tied together using Docker containers. For quickstart checkout the Docker repository and also take a look to the Readme in backends repository.
What’s the current state of the project?
As of January 2023, this project reached end of life. Other projects have reached feature parity and on top of that have a more polished UI. The one use case where this project still outshines them is being a research tool for long term monitoring of representative sample of websites on the Internet.
All the source codes remain available and the app can be self-hosted using Docker.