How Installing An SSL Certificate Turned Into a Three Day Saga
When I start work on a new site, one of my first priorities is installing an SSL certificate. And up until this week, it has always been a fool-proof process.
Back in 2018, I bought my first domain name and purchased a shared hosting account with GreenGeeks. Since then, I’ve used them almost exclusively for all my WordPress projects.
So, when a client came to me with a hosting provider already picked out I was excited to try something new.
Oh, to be that sweet summer child again.
Day 1 — The First Portend
After a quick read through on how to install a Let’s Encrypt SSL certificate in Plesk, I logged into the control panel and…realized quickly that the hosting provider uses a version of Plesk without built-in Let’s Encrypt support.
I then verified that no, this company was not on the list of hosting providers that support Let’s Encrypt.
Without a quick install option, it was time to figure out how to generate and upload a Let’s Encrypt certificate without Shell Access. After crying developer tears into the Certbot Docs for a few minutes, I remembered WordPress plugins exist.
Now, I’m aware installing plugins as a quick fix is a cardinal sin. But with four days to get the site ready for launch I was more than willing to make a small compromise.
After installing WP Encryption, I had that Green Padlock and a secure connection in under ten minutes. Problem solved, right?
Day 2 — Troubleshooting
Minutes after finishing up for the day, I received a message from my client that they were unable to view their website on mobile. Why? Because of the dreaded, “This Connection Is Not Private” security warning.
Assuming the SSL certificate was configured incorrectly, I tested out a Self-Signed certificate from ZeroSSL. It didn’t work. My personal browsers quickly decided the new certificate was invalid.
So, I reconfigured the site to use the cert I installed on day one and did my best to force SSL using the power of redirects and this WordPress Barista article. And of course, when I checked in with my client they were still seeing that damned red padlock.
Finally, I did what should have been done in the first place. I asked for more information. Within two minutes I knew the issue was only happening with Apple iPhones using Safari. A specific edge case like this should be easy enough to find a solution for, right?
And then I got lost in a Stack Exchange rabbit hole. 🐰
The first relevant sounding post suggested checking the domain with SSL labs to identify any issues with the SSL cert chain.
The results came back with only a small note about reconfiguring the server to support TLS 1.3. One confusing deep dive into what a TLS protocol is and why older browsers experience this issue, and I was thoroughly beaten.
Transport Layer Security is something I don’t have the technical background to fully grasp. So, as a last-ditch effort, I submitted a support ticket with the web host and waited to hear back.
Day 3 — The Dumbest Oversight Of My Life
Within 24 hours someone from the support team got back to me.
At which point I learned BrowserStack exists and allows you to test different hardware, OS and browser combinations.
The tech let me know he tested starting with iOS 13 on an iPhone Pro using Safari, all the way down to iPhone 6 on iOS 8. Every single test connected and showed the padlock normally.
After explaining that the issue was on a device I don’t have access to, the only thing he could think of that might be causing the issue was DNS or browser caching.
It was at this moment I remembered several suggestions I had skimmed over to check just that. I assumed, that a basic maintenance task I perform weekly, sometimes daily couldn’t be the issue.
I reached out to my client with a casual “Hey, just curious. When’s the last time you cleared your browser cache?”. To which I received an equally casual “I don’t know. Let me check.”
Sure enough. Problem solved.
