Batch check SSL Certificates on CentOS

Hello all,

I’ve moved to management and don’t get to do the fun stuff as much, but recently I got to script a SSL check as we didn’t have engineering resources to complete the task. Yay!

WARNING: Do not copy/paste code from websites. Sites can inject funny stuff into lines that you cannot see.

Single URL test prep work

  1. Get a Linux VM. I chose CentOS 7, but you could use almost anything.
  2. Get a list of URLs to check.

Install the Qualys SSL checker to CentOS

  1. ssh to your Linux box.
  2. Install the Go language if it isn’t already.
    • sudo yum install golang
  3. Grab the Qualys SSL labs tester binary for Linux. OSX and Win is also available.
    • curl -O
  4. Unzip the binary
    • tar -zxvf ssllabs-scan_1.3.0-linux64.tgz
  5. Make your binary executable.
    • chmod +x ssllabs-scan
  6. Test it out!

Prep work for multiple URLs.

  1. Import our list
    • touch sitelist
    • vi sitelist
    • hit a to edit, and then paste in your URL list
    • hit ESC to get our of edit mode.
    • wq
    • hit enter
  2. Test it on our sitelist.
    • ./ssllabs-scan -json-flat=true -hostfile=sitelist > results.json
  3. Does it look okay?
    • more results.json
    • hit q to exit

Convert to CSV. If your brain has atrophied from being in management and you can no longer read json.

  1. Install epel repo, pip, lxml, and most importantly csvkit. You need epel before you can install pip.
    • sudo yum install epel-release
    • sudo yum install python-pip
    • sudo pip install --upgrade pip
    • sudo pip install csvkit
    • sudo pip install lxml==3.4.2
  2. Convert!
    • in2csv results.json > results.csv
  3. Does it look like a csv?
    • more results.csv
    • hit q to exit

Big thanks to and Qualys


Dude, where’s my vxlan?

Strange stuff happens when you go over 1000 IGMP snooping group on a UCS fabric interconnect. Cisco UCS 6100 Series Fabric Interconnect supports up to 1000 IGMP snooping groups and Cisco UCS 6200 Series Fabric Interconnect supports up to 4000 IGMP snooping groups. Here’s how to check if you’ve taken your vxlan to the limit as vxlan relies on IGMP snooping groups to keep chatter down to a minimum on your switch.

In ESXi:
# use the vmk interface with vxlan running on it. I used 1 in this example.
tcpdump-uw -i vmk1 igmp
On your UCS Fabric Interconnect:
show ip igmp snooping groups

To clean your data you can:
cut -d' ' -f4 (your fabric interconnect output) | sort -u > (new file for fabric interconnect)
cut -d' ' -f5 (your esxi output) | sort -u > (new file for esxi)

Next, run a diff on your two files and anything that exists on esxi but not your FI is your problem! enjoy!

How to Get your Dream Job

I see so much bad advice on finding and getting a job. I want to put my 2 cents out there. This guide is totally IT biased. If you do anything else, my apologies.

STEP 0. Figure out where the heck you want to be

How do you setup a LAN. Hit up ebay and just start buying switches? Heck no. You need to formulate a plan. If you want to get all businessy, then you can do a personal SWOT analysis. You need to figure out where you are and where you want to be. I’d highly suggest hitting up linkedin to look at people with the job title you want. After you find them, scroll down to their experience and tah-dah you have a blueprint for success.

STEP 1. Get an interview

a. Have some sort of online presence be it a *ahem* blog, linkedin, or just something that makes you searchable.
b. Make sure your resume can get passed HR. You need a resume packed with buzzwords. All the fancy buzzwords in the job description you are applying for need to exist in your resume too in some form.
c. Be unique in some way. This is really hard to do. Luckily my 1st job experience was in China so I have a leg up. Bring out something interesting and put it on your resume.

Bonus rant
Must have 20 years of vCloud experience. Har, har. If you are a vCloud genius then the fact you’ve been doing it for under a year will not matter beyond the HR sieve. You’ll probably come along requirements that want someone to have been using a technology longer than it’s been commercially available. It should make is super clear just how meaningless these measures are.

STEP 2. Research for your interview

a. Find out who is interviewing you. Look ’em up or ask about them. Nothing suppresses fear like knowledge.
b. Be familiar with all the technologies listed on the job description. Acronyms that aren’t familiar? Ask about it. It could be an internal name that is totally meaningless on Google.
c. Be familiar with the company and get some questions about the business. Who are your competitors and what feature makes you superior to them?
d. What are your questions about the position? Tailor your questions to your interviewer. CFO interviewing you? Make sure your questions and answers are tinted green for money. 🙂

STEP 3. Demolish the interview with your stellar intellect

a. You are really prepared at this point. On my way to a recent interview, I listened to the vSphere 5.1 PXE boot documentation read aloud for me by my Nexus 7. Pretty freaking nerdy, but it put me in the right mindset.
b. You are well researched. You should be well dressed. You are the right person for the job. Keep all of this rattling around in your brain and you will be successful.
c. If you can’t answer a question, ask for more info and try to answer best you can. Ask what an acceptable answer would be to the interviewer if you give up. The interviewer’s answer will give you some insight into how they think. Engage your interviewer as much as possible to learn who they are.

STEP 4. Offer letter

a. Get the offer letter! Do not do anything rash until the offer letter is in hand. Obviously, a company could actually not hire you or any other sort of evil even after you’ve signed and returned an offer letter, but the chances of that happening are slim.
b. Do you even want to work there? Think about it long and hard.


Bonus advice! Always learn. Learn from every failed interview. They may have gone with an internal candidate and you never even stood a chance. If you were asked a question you couldn’t answer, you better be able to answer it next time. Do not get frustrated or discouraged. Every interview makes you that much better for the next one provided you keep up good habits and continue to study.

If you are not getting any interviews at all, then something is wrong. You need to talk to a head hunter, colleague, or just anyone at all to get some feedback. Applying in the wrong region? Wrong skills? Just find out what you are lacking and go out there and get it.

Difference between a System Administrator and a Developer

3 + 3 to a Developer is 6
3 + 3 to a Sysadmin is 6, but sometimes it can be 3 or 78

This is not meant to be a slight. It just seems that devs look at how it is supposed to be and sysadmins look at possible outcomes. I have to catch myself before I get too deep into a gajillion contingencies. I naturally think about when it goes wrong more than when it goes right. What do you think? How does a project manager think? 🙂