Troubleshooting SSL Silliness: When time is not on your side

This quick hit was brought to you by the letter “T”, because Tea is yummy and I can’t tell you the person who inspired this post because he has access to my morning Tea. See? The letter T! ANYWAY, SSL is a good thing overall, but sometimes it can get a little bit annoying to troubleshoot – especially if you don’t deal with it every day.

Here’s the setup.

A developer was using a library to connect to an API (server side, this is important) in a virtual dev environment, and he was getting the following error:

I immediately thought, “The time is wrong on the box,” because “not yet valid” is a huge giveaway. So, I asked what the date and time were in his environment. He replied, “Mon Feb 12 20:52:47 UTC 2018” and also added, “not wrong enough to break it though” – which isn’t accurate (not his fault, he’s a developer and not a cryptologist) and here’s why.

All time things are important.

SSL certificates (or TLS if you prefer) have what is called a “start-of-validity” date. This allows you to validate a certificate “in the past,” which also sounds really complicated… because it is. So I’m not going to explain the why of it, just that it exists and is as important as the expiration date – just in reverse. All this means is that each SSL certificate you encounter would have a start date (notBefore) and an expiration date (notAfter), and if the time is wrong on your client or server you’re going to have a bad time. All things time matter, they just do.

For the good of all humankind, make sure clients and servers are time synced in your environment.

The troubleshooting steps then went as follows.

After seeing the “notBefore” output, and already knowing the incorrect time (Feb 12) on the system, it was pretty easy to conclude that time was the problem. Once we went in and told his environment to use the NTP Pool, the time synced up, the problem was solved, and crisis averted.

Now, you might be asking yourself, “Self, is this as important to check in VPN setups?” and the answer is a resounding yes. Throughout many years (more than I care to recall or count), I have “one-call closed” many tickets simply because the VPN endpoint on the other end thought it was Friday instead of Monday. I had to ruin that poor endpoint’s whole week.