jarnovos

Hi @aclassifier,

While those URLs indeed seem fine at first glance, you could always reach out to your host and ask them to review your configuration.

Just to further clarify the difference between these redirects: the .htaccess redirect (such as the one you’ve configured manually) happens at the server level, so before WordPress is even loaded. And the 301 PHP redirect (the one that you currently have enabled in this plugin) occurs later in the process, after WordPress has loaded. This means that if a .htaccess redirect is in place, it will always take precedence over the PHP redirect.

Kind regards, Jarno

Hi @aclassifier,

I’ve reviewed the points you provided, but I am not entirely sure whether I fully understand all of them.

From what I can see you’re currently not using the 301 .htaccess redirect provided by Really Simple Security; and as your question seems to concern a redirect rule that isn’t set by (or managed through) this plugin, this makes it quite difficult for me to accurately diagnose or address the behavior you’re seeing.

While I’m happy to provide support for features within the Really Simple Security plugin, I am not able to fully assist you with debugging configurations ‘outside’ of the plugin’s scope.

I’d try either temporarily disabling your custom redirect and enabling the 301 redirect through Really Simple Security to see if it fixes your issue. You can test your https:// URLs in a tool such as https://redirect.li/ to see if they are properly being redirected to https://, so you can be sure it is not a browser related problem.

Kind regards, Jarno

Hi @aclassifier,

Okay, so you’re currently using a .htaccess redirect from HTTP to HTTPS other than the one added by this plugin? This didn’t immediately become clear to me from your initial post, I thought your question related to the 301 .htaccess redirect from this plugin.

You could try switching to the plugin’s 301 .htaccess redirect instead. The plugin’s version is slightly more robust with a check to ensure that mod_rewrite is available before applying the rule; and uses a case-insensitive HTTPS check.

While the .htaccess redirect shouldn’t cause issues you can always follow these steps to revert the change (https://really-simple-ssl.com/remove-htaccess-redirect-site-lockout/) if that does turn out to be necessary.

Kind regards, Jarno

Hi @gurumance,

I see, while the plugin would work fine on WP Multisite environments; it is important to note that clicking “Activate SSL” in this case would enforce SSL on all of the (sub)sites at the same time.

Which would explain the behavior that you described earlier 'i thought it will touch only the dummy website i use for testing'.

Kind regards, Jarno

Hi @aclassifier,

Have you already clicked the Activate SSL button in the Really Simple Security Dashboard, as this will enforce HTTPS on your site?

If so, but things don’t seem to work as expected yet, you can try switching from the standard 301 PHP Redirect (WordPress redirect) to a 301 .htaccess redirect.

Kind regards, Jarno

Hi @gurumance,

This would be challenging for me to say without knowing the exact error message that you encountered, but the plugin does the following when clicking Activate SSL.

– Add fixes to the wp-config.php (if necessary).
– On Apache servers and if you enabled the .htaccess 301 redirect option, it adds the 301 .htaccess redirect to https://
– Changes site and home URL to https://
– Dynamically fixes mixed content

Summarizing, all you should have to do in case of such an issue is to roll back the wp-config.php, .htaccess, and the Site and Home URL changes in the WordPress Settings. Since all of the sites seemed to be affected, it sounds like the .htaccess change may have been related.

Given your explanation about which method resolved the issue; it sounds like HTTPS was enforced on all sites on the server, but since your server was not correctly configured for SSL/HTTPS usage (e.g., due to an ERR_SSL_PROTOCOL_ERROR), this prevented access to the sites as they were enforced to use HTTPS.

Kind regards, Jarno

Hi @gurumance,

You can safely remove the “ssl” folder, as it would only contain SSL certificates generated with the plugin.

Though I don’t quite understand how the plugin would be able to affect a site where it hadn’t even been installed yet. Could you provide some more information about the error message you’re seeing on such an environment?

Kind regards, Jarno

Hi @computergoingoutwindow,

Your server experiences a 500 Internal Server Error, meaning; the error occurs before WordPress has loaded. As WordPress isn’t actually running yet, it won’t be able to generate the debug logfile either.

Instead, you will likely want to check the server’s error logs (instead of the WordPress debug logfile) to see exactly what actions the server is trying to perform when this error occurs. This should tell you more about what causes the issue.

You can always ask the support team of your hosting provider where you can find the server/PHP error logs in your case.

I hope this somewhat clarifies the behavior you’re experiencing.

Kind regards, Jarno

Hi @hombreimaginario,

Great, appreciate the quick confirmation as well!

Feel free to reach out to us if you have any further questions about the plugin.

Kind regards, Jarno

Hi @hombreimaginario,

While you can always send us a message with the Support Form on our website (https://really-simple-ssl.com/support/), we’re also active on the www.remarpro.com Forums; so this is perfectly fine as well.

If I understand correctly, you are receiving the confirmation email in your inbox as expected, but clicking the verification link does not result in the address appearing as verified in the plugin?

If this is indeed the case; the most important part is that you are receiving the email in your inbox, as this confirms that your site is correctly configured to send email.

You can therefore force complete the e-mail verification by navigating to the Security tab in the left-hand WordPress Menu, then paste the following line behind the URL in the address bar: &rsssl_force_verification, press Enter to visit that URL and the verification will be completed.

Kind regards, Jarno

Hi @pabval2,

This issue will be resolved in the next update of the plugin, but you can already obtain the version of Really Simple Security containing the patch by clicking here.

You could also download it from GitHub instead.

If you can’t access the WordPress Admin Panel due to the issue, please follow the steps listed in this article to deactivate 2FA temporarily: https://really-simple-ssl.com/instructions/disabling-2fa-when-you-are-locked-out/

This should allow you to access the WP Admin once more and install the new plugin version including the fix (Plugins -> Add New -> Upload Plugin). I’d also recommend Resetting the 2FA status of your Account prior to re-enabling 2FA (Security -> Settings -> Login Protection -> 2FA -> Users -> Reset), because it looks like your Grace Period to configure 2FA has expired.

Kind regards, Jarno

Hi @esmertec,

Yes, I can definitely understand why you wouldn’t want to disable all notifications, such as the ones about vulnerable plugins being detected on your site.

If you just want to get rid of these Site Health notices (specifically the ones about LLA / Firewall / Security Headers), you could use a code snippet like the one below to manually remove these.

You can add this code in a new .php file and place it in the /wp-content/mu-plugins/ folder on your site for it to take effect.

<?php
// Removes the 2FA, LLA, Firewall and Security Headers notice from Site Health overview
add_filter('site_status_tests', 'remove_rsssl_tests', 10, 1);

function remove_rsssl_tests($tests) {
    if (isset($tests['direct']['headers_test'])) {
        unset($tests['direct']['headers_test']);
    }

    if (isset($tests['direct']['rsssl_firewall_test'])) {
        unset($tests['direct']['rsssl_firewall_test']);
    }

    if (isset($tests['direct']['rsssl_lla_test'])) {
        unset($tests['direct']['rsssl_lla_test']);
    }

    if (isset($tests['direct']['rsssl_2fa_test'])) {
        unset($tests['direct']['rsssl_2fa_test']);
    }

    return $tests;
}

Hope this helps. Kind regards, Jarno

Hi @esmertec,

Indeed, the Security Header test results of your site look perfectly fine. The Site Health notice is cached for performance reasons, so the notice about these headers might not disappear immediately upon configuring the recommended Security Headers.

The notices about Limit Login Attempts and the Firewall will disappear if you enable the relevant functionality, which can be either in our plugin, or in another plugin that also includes said functionality.

But if you don’t want to see any of these Site Health notices at all, you can simply activate the setting “Dismiss all notifications” under Security -> Settings -> General and they will disappear regardless of your configuration.

Hope it helps/clarifies. Kind regards, Jarno

• This reply was modified 2 months, 1 week ago by jarnovos. Reason: typo

Hi @gregnowak,

I definitely understand the question and use case here, but at the moment there is no built-in method in the plugin that prevents the creation of those folders. Note that the actual files (e.g., the .crt files) for the SSL certificates would only be created upon actually completing the Let’s Encrypt Wizard in the plugin.

In any case, I will absolutely raise this as a feature request / suggested improvement within the team though, so it’s on our roadmap for an upcoming version of the plugin.

Coincidentally, we are currently in the process of reworking the WP-CLI capabilities of the plugin. Once this nears completion, we will publish further documentation to describe all of the available commands and possibilities.

Kind regards, Jarno

Hi @g_abriel,

I’ve already answered this question in your thread on the Really Simple Security forums, but just to provide you (and potentially other users who might come across this post) with the answer as well:

You most-likely have the setting Disable “anyone can register” activated in Really Simple Security, under Security -> Settings -> Hardening -> Basic in the plugin.

After disabling this option and saving the settings you should no longer experience this behavior, even with Really Simple Security enabled on your site.

Kind regards, Jarno