Show HN: SSL certificate dashboard | Hacker News Reader

Show HN: SSL certificate dashboard

github.com

45 pointsJens_18 comments

A better approach is to have an automated alert for certificates that are expiring soon (next X days) then sending out an alert. Or even better, switch to automatically rotating certs on a regular basis via letsencrypt.

Rotating certs is like restoring backups, if you only do it when shit hits the fan (server crashed or cert expired), you're doing it wrong.

> Rotating certs is like restoring backups, if you only do it when shit hits the fan (server crashed or cert expired), you're doing it wrong.

you restore backups even if the server is still ok? why?!

How do you know if your backups are good? Better to test a restore when everything is still working fine rather than waiting until you really need it and then finding out that your backups are broken.

these 2 dashboards have a lot of in common...

https://github.com/JensDebergh/certificate-dashboard https://github.com/cmrunton/tls-dashboard

He did say he saw a similar project on GitHub.

"I've seen a static version of this project on github, but I forgot the name of the original project. It is his static version of the dashboard turned into a configurable service that spits out HTML & JSON."

EDIT:

I think he gave proper credits.

Yes, and the other project was on here just 4 days ago [1]. I had actually tried it out myself so I was surprised to see this.

Just writing:

> I've seen a static version of this project on github, but I forgot the name of the original project. It is his static version of the dashboard turned into a configurable service that spits out HTML & JSON.

is unfair to the original author and just doesn't cut it in this case. I see that the MIT license is there, but the original [2] has this line added to the copyright notice:

> Copyright (c) Craine Runton

The MIT license requires reproducing the copyright notice in full, that includes this line as well. Even if it's just small parts of the original project that were used/modified.

It's very cool when someone makes their work available for everyone to see and use, it's not cool to just steal it and even go so far as to rename variables from the original just for the sake of it, see commit [3] (e.g. config.js)!

And even after that, the code still looks very similar. Just take a look at config.js [4-5] and get_cert_info.js [6-7].

[1] https://news.ycombinator.com/item?id=11770856

[2]https://github.com/cmrunton/tls-dashboard/blob/master/LICENS...

[3] https://github.com/JensDebergh/certificate-dashboard/commit/...

[4] https://github.com/cmrunton/tls-dashboard/blob/master/node_a...

[5]https://github.com/JensDebergh/certificate-dashboard/blob/ma...

[6]https://github.com/cmrunton/tls-dashboard/blob/master/node_a...

[7]https://github.com/JensDebergh/certificate-dashboard/blob/ma...

Frankly saying I'm not 100% sure who copied the code from other. Cmrunton's version is younger than Jens' one (based on the repository history and commits), but Jens admits that code for the dashboard was picked somewhere.

Code is, clearly, very very similar, I've checked both dashboards, this why I've posted the initial comment.

Jens' first commit [1] was 3 days ago, the repo is a fork of the node-js-getting-started example repo and all older commits [2] are not by him and related to that repo.

Craine's project was already done and posted here by then [3], the situation is very clear here.

[1] https://github.com/JensDebergh/certificate-dashboard/commit/...

[2] https://github.com/JensDebergh/certificate-dashboard/commits...

[3] https://github.com/cmrunton/tls-dashboard/commits/master

:thumbs up:

You are right its the exact same dashboard. I never said it was original. I've used the static version of crumtons project and turned it into a configurable webservice. While doing so I copied and modified code from the original project, wrote some tests and published it as is.

I didn't remember the name of the original author/project, until someone linked me towards the github page. Since then I've added a proper link.

It was never my intend to steal copyrighted material. I just wanted it to be done how I thought it should be done.

Hi Jens_. I'm the one who wrote the TLS certificate dashboard that the other posters are referring to here. While I don't mind people forking the dashboard I made and modifying it for their own purposes (that's why I put it up on GH after all), I do mind when proper credit isn't given for the work that I've done. I'm not interested in starting a war of words on the Internet, so all I'll say at this point is that I appreciate that you've updated your readme with a link to my project and added the license to your repo. Have a great day.

I spent a weekend building a certificate dashboard right into Calendar.app. The front-end may not be React and the back-end definitely isn't written in Go, but it works really well. I didn't even need to install Redis or another NoSQL database. The CRUD is outstanding and the search support is great, even if its not based on Solr.

I ported my solution to both Google Calendar and whatever that thing is that would be the Microsoft equivalent. Full mobile support, entirely cross-platform. You can even use it on someone else's computer I mean cloud.

This is easy to do with Nagios and the check_http plugin, and Nagios is then your dashboard for not just SSL expiration but every other service you are (or should be) monitoring as well.

Simple if you already have Nagios set up and running... far from simple if you haven't.

Though someone here posted a video a couple of years ago where the speaker was imploring "Stop using Nagios [it's terrible]". At the end, someone asked him what they should use instead, to which the speaker didn't have an answer (his tool that he was speaking about was still in development)

Edit: but yes, you're right in that the important thing is that the tool will alert you without you having to remember to check it.

Here's a command-line one written in Go: https://www.opsdash.com/blog/check-ssl-certificate.html

If you clone my sysadmin utilities, from here:

https://github.com/skx/sysadmin-util

You'll find:

     $ ssl-expiry-date bbc.co.uk
     bbc.co.uk
        Expires: Mar 15 17:01:06 2017 GMT
        Days: 289

That uses openssl, bash, and other standard facilities available upon Unix/Linux systems.

Very cool! We use Jenkins to check when our SSL certificates are approaching 30 days until expiration. A simple call to openssl(1) works great!

Good stuff!

Reply on news.ycombinator.com