How to create a load balancer SSL/TLS certificates report

A customer asked me the other day how to export a list of SSL/TLS certificate expiry dates from our load balancer appliance.  

Here's what I told him...

The problem: need to monitor load balancer SSL/TLS certificates

For background on why load balancers need SSL/TLS certificates and the consequences of expired or broken certificates, check out this blog: Effortlessly monitor load balancer SSL certificates with the ADC Portal.

But for now, let's just crack on with the customer ask and our recommended solution.

So what was the request? It went something like this:

"Is there a simple way to get a list of SSL/TLS certificates with their expiration dates from the load balancer? I see that we could call "[LBIPAddress]:9443" over and over again, starting at 0 and continuing along the same lines until it runs out of certificates. But is there anything better? We keep expiration dates in our database, but are concerned that some of them may have gotten out of sync."

I put my thinking head on, knew I had done something like this for a previous customer, and allowed my fingers to do their thing!

The solution: Use this simple script to automate reporting (v8.5.8 and below)

Scripting is one of the fun tasks we get to do here at Loadbalancer.org, and here's how I used it to answer this particular request.

First, I wrote the interface and linked it into the very simple API wrapper so it was secure, didn't take any args, and simply returned the data in JSON format:

The script walks the XML for all certificates and then checks if the file is present. If it isn't present, it will return the JSON below:

The script walks the XML for all certificates and then checks if the file is present. If it isn't present, it will return the JSON below:

So now we have:

1) The script to read the certificates present, and

2) We also have the return data format

Then we wonder, how do we call this?

Well, put simply, we run a simple HTTP GET Request, as seen below with a cURL example:

Now those who've read my previous blogs will recognise this script is simply the same as that in my APICALL script (only here I've changed it from POST to GET request and removed the need to send any JSON). We only need the output here, but you don't use Linux as you don't have cURL present, so you need another way to call and retrieve the JSON output.

We can use any language that will perform a HTTP GET, so that leaves us with my normal (Powershell) or C#.

Knowing the customer used C#, I'll use this as an example...

This also makes sense because golang is, well, "EASY" to code and makes an .exe file for Windows, Mac or Linux.

As you can see from the above, golang is kinda 'wow'...!

But is the script really that simple? The answer is yes! Anyone with the aptitude and wish to learn can be posting data within an hour (it took me just 10 mins to find and implement this when I looked, and its cross-platform so no more scripts to do things! Go golang!).

What about compiling?

So, you have a script, but now you ask about compiling? That's hard right? Well no, it's simple.

One would just type go build scriptname.go to build a binary or .exe on Windows and go run scriptname.go to test it.

I was up and running with my first sensible script in a matter of hours.

Why walk when you can run?

And there you have it. Customer ticket closed in record time. Hopefully this solution is helpful to others. It enabled another form of automation — this time for a report that did not exist.

If you have any questions please don't hesitate to ask our technical team. Attaching the  /var/log/lbadmin.log to your ticket should be enough to fix any problems.

Alternatively, you can make your life EVEN EASIER by using our centralized management platform, the ADC Portal, to effortlessly monitor SSL certificate expiry dates from a single window of control:

And the best bit is that with the ADC Portal you can see not just the certificate expiry details of our load balancers, but also those of your F5, Citrix, and Kemp appliances too!