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.
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.
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'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."
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].
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.
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.
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.