Upgrade to SSL Breaks Admin Dashboard

I am currently running an instance of WordPress, version 4.5.3, on an Amazon EC2 server. It uses:

• CentOS 7 (OS) and has SELinux enabled.
• Server runs Apache with mod_security and mod_evasive
• PHP 5.6.24

The site’s name is The Rambling New Yorker.

Not long ago I upgraded to SSL using Let’s Encrypt. The process was fairly simple and I now have the front end secured. I’ve even installed a plugin which redirects non-SSL traffic to the secure site.

Unfortunately, the admin dashboard is broken. As soon as I did the switch over it started looking as follows:

I’ve changed the URLs (in the database, not through the dashboard) to be the SSL version and enabled “Force SSL Admin” in the config file. The login page is fine.

The switch over once worked when I disabled all plugins. Re-enabling them one by one led me to believe WP Super Cache may be the issue, but when I did the switch over after deleting the plugin, the problem recurred.

Disabling mod_security eliminates the problem, but there are no helpful error messages in the Apache error logs so I don’t know what’s upsetting it.

The only clue is that requests for load-styles.php and load-scripts.php return a 403 error:

However those files have the same ownership (apache:apache) and permissions as every other file in the wp-admin folder (644). So I am clueless. Does anyone have an idea what the underlying cause might be?

Update – 8/26
Based on some research I came to the conclusion the PHP error noted in the comments below was related to not having a particular extension – mbstrings – installed. Unfortunately when I went to install it, I tried to install the wrong version, then uninstalled some packages, added the Remi repository and then installed some packages which weren’t quite the same as the old ones. My server runs PHP 5.6.24, but some of the packages may have been from 5.4. WordPress stopped working. After flailing around for a bit, I just rolled back the server to the AMI created before embarking on my SSL adventure.

I’m going to try to migrate to SSL again this weekend. If the problem recurs, I’ll be back here. If not I’ll post an answer. Either way I’m going to avoid altering the database if at all possible.

Update 2 – 8/27
The secret ingredient was the package php56u-mbstrings. Once I installed it, the script worked fine at the command line, although the GUI kept throwing AJAX errors and would only search three tables. The CLI script replaced 31 instances of http://www.ramblingnewyorker.com with https://www.ramblingnewyorker.com. However the problem persists. It appeared from the moment the secure site was set up. Disabling mod_security, or adding the following lines to my ssl.conf file do fix the issue:

<LocationMatch "/wp-admin/load-scripts.php">
    <IfModule mod_security2.c>
        SecRuleEngine Off
    </IfModule>
</LocationMatch>
<LocationMatch "/wp-admin/load-styles.php">
    <IfModule mod_security2.c>
        SecRuleEngine Off
    </IfModule>
</LocationMatch>

Due to the security implications I’ve commented those lines out. This would seem to be related to mod_security somehow, but I can’t find a single error message in the Apache log files.

Not sure what plugin you are using to enforce SSL, but I would disable it to prevent conflicts with the possible solution below.

To make sure you’ve updated all of your URLs to the HTTPS, do the following:

1. Go and download Interconnect IT’s Database Search & Replace Script here
2. Unzip the file and drop the folder (Search-Replace-DB-master) where your WordPress is installed (the root) and rename the folder to replace (screenshot)
3. Navigate to the new folder you created in your browser (ex: https://www.ramblingnewyorker.com/replace) and you will see the search/replace tool
4. It should be pretty self-explanatory up to this point: enter your HTTPS link in the search for… field and the new HTTPS link in the replace with… field

You can click the dry run button under actions to see what it will be replacing before you execute the script. Once you’re done be sure to remove the /replace/ folder.

This will help ensure that you are full running your website on the new SSL (https://) links. If you’re still having issue, let me know. So we can figure out the next step.