Really Simple SSL is fully multisite compatible. In combination with Really Simple SSL Pro multisite you get full control over your multisite SSL setup. The different options you have when activating for multisite can be a little daunting, so in this article I’ll try to explain what your options are, and when you need to choose a particular setup.
Setting up Really Simple SSL in a multisite environment
Really Simple SSL (free version) can be installed by uploading and activating the .zip file in your WordPress installation, or by installing it directly from the WordPress repository.
Like all plugins, you can choose to either activate Really Simple SSL networkwide, or just on a specific site. When activated on just one site, it will behave like on any single site installation. However, I would recommend activating networkwide, as you can still choose to activate SSL per site. In addition, the networkwide option gives you the network SSL settings menu, which gives you full control over your settings. You can now hide the SSL menu for your users, and activate or deactivate sites from one central place: the network settings SSL menu.
Please note that Really Simple SSL Multisite needs Really Simple SSL to be activated networkwide.
After activating networkwide, you will be presented with the choice to either activate SSL networkwide or activate SSL per site:
Activating SSL networkwide:
Activating SSL networkwide will enable SSL for ALL sites in your multisite installation, even if a site does not have an SSL certificate.
Activating SSL per site:
Activating SSL per site allows you to define the SSL options on a per site basis. You can have some sites on http, and others on https.
In both cases it’s still possible to set the options on a per site basis, as long as it’s networkwide counterpart is not enabled.
Network settings menu
The networkwide options menu provides almost the same functionality as the Pro plugin, with the added ability to apply these settings networkwide. The differences between the two are outlined below:
- Enable SSL networkwide or per site
This option selects whether the plugin should apply the settings networkwide or on a per site basis. This option makes it possible to switch between network wide or per site activated SSL. Please note that switching to per site activated will deactivate SSL on all sites, so you will have to enable it per site afterwards.
- Hide menu for subsites
This option hides the menu from all sites.
- Enable htaccess redirection to SSL on the network
This option applies .htaccess redirect rules for all SSL activated sites on the network.
Per Site options
The per site options are identical to those found in Really Simple SSL and Really Simple SSL Pro. But if a networkwide option is enabled, it will override the per site option. Example: if you enable .htaccess redirect on the network settings menu, this will enable .htaccess redirect on the subsites where SSL is activated, regardless of the site setting.
When the plugin is activated networkwide, the ‘Sites overview’ shows all sites as having SSL. This is default behavior since the plugin has been activated networkwide and thus set all sites to SSL.
When the plugin is enabled on a per site basis, the ‘Sites overview’ changes. SSL is disabled by default and the menu provides an option to activate or deactivate SSL per site, as shown in the image below:
This option also comes in handy when you find yourself locked out of a subsite. In the event you are locked out, try to deactivate SSL on the subsite you can’t access to see if that allows you to log back in again. Note that if you keep experiencing issues with logging in there might be something else that is causing it. Some other possible reasons why you can’t log in are:
- Domain mappings may be deleted and need to be reconfigured after the base SSL domain is configured.
- Incorrectly configured certificates
It is also worth noting that it can help to change the login URL from https://yoursite.com/wp-login.php (network) to https://yoursite.com/wp-admin (direct site login).
Domain mapping tips
- HTTP (A) to HTTPS (B) redirects will always work as long as domain B has a valid certificate.
- HTTPS (A) to HTTPS (B) redirects require both A and B to have valid certificates.