For the past three months, I’ve tried my best not to have a mini meltdown over the fact that a number of my domains in a WordPress multisite network using Cloudflare’s free Universal SSL would not serve up a green padlock over HTTPS. When I first heard Cloudflare was offering free Universal SSL, I was very excited to take advantage of it. For some reason, it just wouldn’t work and for months, I couldn’t figure out why.

Now that Google is using HTTPS as a (minor) ranking signal, I want to make sure all my domains are using SSL. But even after enabling Universal SSL on Cloudflare for each domain, the one’s using the new service were void of the green padlock that tells the world each domain in my little network could be trusted. After struggling with it a bit to no avail, I thought I’d better buy a three site SSL certificate from my preferred domain name seller, Namecheap.com, for three of my most important domains. A temporary fix for 3 domains in an 11 domain multisite network.

After WP Engine installed the Commodo certificate for me, all three sites were instantly padlocked after. Since the others were not as much of a priority, I continued to ignore no green padlocks on them, but it just kept on nagging at me they weren’t locked.

It’s in my nature to incessantly focus on problems until resolved. While others might not care as much as I do or they pass the buck to someone else, I always go to the end of the earth (despite my better judgment) to figure it out myself. I don’t know why I’m like this. It’s a blessing in some ways, because I actually get things done–no matter what. It’s a curse in others, because I do it all myself and am so focused that it can take hours and hours of painstaking work to figure out the solution. In that, I’ve let the world go by while I’m trying to solve a problem I should pay someone to solve for me. But, then I’d have to give them all the passwords and account access to both my network install, Cloudflare, and WP Engine. Without a clear path to resolution, who knows how many hours someone could take to figure it out. And, who knows if you’re even talking to the right person who can figure it out.

Night after night, I would go back through my Cloudflare install and make sure all domains were set to Flexible SSL. Then I’d dump my cache at Cloudflare and in my WordPress WP Engine network admin. I tried a various plugins to see if the URLs did would not redirect and cause a loop. Nothing worked.

I made sure to get the Cloudflare plugin to connect my multisite network to the service, but I was getting some errors and I needed to research how to make sure the Cloudflare plugin connected via their API to my account. I turned off my Cloudflare service for all the domains that had no green padlocks. Of course, the API wouldn’t connect if they were off. I turned them all back on and made sure they were all set to Flexible SSL again. Once I solved that, I thought: “Great! Problem solved. My padlocks should be green!”

Nope, that didn’t happen.

After some lengthy discussions with WP Engine support on this matter, I learned I was getting a lot of mixed content and insecure content warnings on some of my domains in the network. Why? Because somehow my URLs had gotten rewritten either in the original migration from Linode to WP Engine or by some process or plugin. I’ll never know how that happened. Two of my sites were missing all of their content and their URLs were rewritten incorrectly for posts and pages in the database as “netmix-co.netmix.co” instead of “primarydomain.com/sitename.

Tasked with figuring out the underlying problem, I went in and performed search and replace surgery on all my domains using phpMyAdmin. I was able to go into my posts and post meta tables for each site in the network and find the incorrect rewritten paths. I simply replaced the incorrect ones with the correct domain names of each site in the network. That solved a ton of insecure content warnings and brought back all my missing content while also fixing redirection issues.

Now that I’d solved a number of problems using search and replace, some were still lingering. My JavaScript console reported affiliate network URLs I was using from organizations like Shareasale were http, not https. Fortunately, Shareasale provides secure URLs, but other affiliate partners did not. I had to remove their banner codes until they update their URLs to https.

Having done all this, I was pretty confident I’d see the green padlocks, but when I checked whynopadlock.com, all the sites with Cloudflare Flexible SSL turned on were hard redirecting to http. I thought, “geez, now how do I solve this?”

Earlier that week, WP Engine had helped write some html post processing logic that is set in my multi-site’s WP Engine admin area. Could that be the culprit? I removed those rules to see if anything changed.

Nope, that didn’t work either.

In the middle of all of this, let’s throw in the fact that WP Engine had to move my web services to another IP address last week after their provider was hit with a DDOS attack. I was tasked with updating all 11 sites A Records in the network. I did and learned that one of my sites had no DNS records at all (Oy!), but was still resolving. Go figure.

I went back to WP Engine again to explain my dilemma again. Fortunately, I got in at 3 minutes to 9 pm Eastern time, just minutes before chat support closed up for the night. I gave one of WP Engine’s techs, Brian F., all the earlier detail. His head must have been spinning. But, he finally figured out that they had to manually force https on their end to enable the green padlock on all sites in my network.

Finally, it was over. After months of starts and stops and weeks of going back to it, getting distracted by family stuff and client work, I was able to sit down and go through everything once and for all. Problem solved.

While all the abovementioned things I did were important, Cloudflare did tell me in one response they were seeing WP Engine had the ability to do something on their end to fix this, but they didn’t say exactly what that was. With Universal SSL, WP Engine does not have to install a certificate. It’s a one-way call to WP Engine who do not have to confirm the request with an installed cert. What they didn’t say was that WP Engine has to manually force HTTPS. It wasn’t until Brian F. figured this out that the curse was finally over.

I did not use a Force HTTPS plugin, because I think WP Engine disallows a few of them. I don’t know that they would have worked anyway. I’m was happy to have WP Engine manually write that rule every for this instance and in the future. At any rate, the problem is resolved. On to the next issue.

I hope this helps someone not have to go through weeks of pain like I did to finally figure out that all WP Engine had to do was force HTTPS manually. That’s it. Problem solved.