
Show HN: TLS cert expiration dashboard - craine
https://github.com/cmrunton/tls-dashboard
======
craine
I created a dashboard to view some basic info about the TLS certificates that
I manage for various websites, including days to expiration, Issuer, Issuer
Common Name, and certificate common name. It's also useful for enterprise
infrastructure if you have to manage lots of web server certificates as part
of a security or ops team.

I use a node module to scrape the peer certificate info, and then dump it into
a file that a web page picks up. It's not real-time, out of concern for too
many people hitting or reloading the page and kicking off too many connection
attempts at once.

An example is here: [https://craine.gitlab.io/tls-
dashboard/](https://craine.gitlab.io/tls-dashboard/)

------
Pirate-of-SV
I would really appreciate if browsers could implement some kind of Javascript
API for retrieving Cert information of the current page. (In my opinion it
would make more sense than the Battery Status API [1])

[1] [https://w3c.github.io/battery/](https://w3c.github.io/battery/)

~~~
JoshTriplett
For the current page? What could you usefully do with that information? You
should know what certificate you're serving, and if it isn't that certificate,
the page is hopefully not being displayed at all. The browser should be
protecting the user from MITM.

------
jhallenworld
Well, start a company: [https://www.venafi.com/](https://www.venafi.com/)

I know of an enterprise that paid for this feature: "warn me when my certs are
about to expire."

~~~
unethical_ban
You may laugh. But in an enterprise, it is the CA's job internally to help
manage and communicate expirations to users. If there are 10,000+ certs in an
org, you want a tool to manage them.

~~~
craine
Fair point that it's the CA's job, but typically their solution is "We'll send
you emails at certain thresholds". That kind of thing tends to get lost in the
noise of daily work, especially at places with poorly defined processes.

I've also worked places that used multiple CAs, and that makes it more
difficult to manage. This at least can pull the info in based on what the
server is actually using, and puts everything on one screen, regardless of the
CA it came from.

------
michaelmior
This looks great! But hopefully as ACME[0] becomes popular there won't be a
need for tools like this anymore.

[0] [https://github.com/ietf-wg-acme/acme/](https://github.com/ietf-wg-
acme/acme/)

------
voxio
Personally I just integrate these checks into existing monitoring systems. For
example, for sensu I use: [https://github.com/sensu-plugins/sensu-plugins-
ssl](https://github.com/sensu-plugins/sensu-plugins-ssl)

Domain expiry is also another one people sometimes miss that should be
integrated into existing monitoring.

------
blakesterz
This is great. I've been meaning to find a way to keep track of TLS like this.
Anything other ways to do this?

~~~
dthakur
I've been working on a hosted version of such a service. This is just the kick
I needed to finish it up.

Keep an eye out for 'Show HN: Expiry alerts' this weekend.

------
voidz
I use the tool 'xca' for this. Really useful tool that supports various
operations with certificates and CSRs. It uses Qt.

[http://xca.sourceforge.net](http://xca.sourceforge.net)

