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:

WordPress SSL Problem

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:

WordPress SSL Problem #2

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
<LocationMatch "/wp-admin/load-styles.php">
    <IfModule mod_security2.c>
        SecRuleEngine Off

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.

  • I see you have http://localhost:27275/command links in your second screenshot, are those suppose to be there? Aug 23, 2016 at 21:14
  • I have no idea and didn't even notice them until you pointed it out.
    – Mike P
    Aug 23, 2016 at 22:18
  • Were you running the website on a localhost before and migrated it over to your live host? If so, I'd follow the steps in my answer to replace that as well. That could definitely be a big factor. Aug 23, 2016 at 22:47
  • No. I was running the website on a different server and migrated to a new one. The old server ran Amazon Linux and I wanted to create a development environment I didn't have to pay to turn on. Once I set up my current server I exported the content from the old instance of WordPress and imported it into the new one. The localhost line didn't appear when I loaded the site on my work computer just now despite the browser being the same so there might be something odd going on with my laptop.
    – Mike P
    Aug 23, 2016 at 23:17
  • I see. The let me know if my answer below fixed anything. Aug 23, 2016 at 23:37

2 Answers 2


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.

  • 1
    Alternative to that script - wp-cli's search-replace command
    – Tim Malone
    Aug 23, 2016 at 21:41
  • @TimM, I will likely install wp-cli regardless of the cause of the issue. It is nice to have an alternative to the GUI. I use WP Force SSL to do the redirect, although it might be possible to use either the .htaccess or apache config files instead. Could the problem be lingering HTTP links somewhere in the database?
    – Mike P
    Aug 23, 2016 at 22:33
  • @MikeP That's exactly what Ethan's answer is trying to address for you :)
    – Tim Malone
    Aug 23, 2016 at 22:34
  • @MikeP Yes, like Tim mentioned, disable the WP Force SSL because it looks liek you are having a conflict. Aug 23, 2016 at 22:46
  • Deleting the plugin did not help. The Search and Replace script kept throwing errors. The GUI gave me an ajax error (even with all security disabled) and the CLI returned an error about an undefined function. Would it be easier to reinstall WordPress, setting the site url to be https from the get go?
    – Mike P
    Aug 24, 2016 at 4:00

Problem solved! The cause turned out to be dead simply. One of the mod_security rules was interfering with the admin dashboard loading. I didn't notice this earlier because I had failed to check the SSL error log (owing to my not knowing it was there). As soon as I did so, and disabled the offending rule for the files which weren't loading everything was fine.

  • Could you add more details please? What should I do to prevent it?
    – user150610
    Sep 14, 2018 at 0:51
  • @DmitryGrinko I don't recall the exact rules I disabled, but my approach was essentially to turn off specific rules for specific pages. This can be accomplished by using the LocationMatch directive in the Apache config file and SecRuleRemoveById to target a certain rule. See here for an example: link . You can find the rules, which are causing problems by looking through the Apache and SSL error logs.
    – Mike P
    Sep 14, 2018 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.