jarnovos

Hi @bulls_shark,

You can deactivate these notices by enabling the “Dismiss all notices” slider under Security -> Settings -> General in the plugin.

We will expand the detection for LLA to include Solid Security as well, to avoid showing this notice if it’s enabled in that plugin.

Though with regards to the Security Headers notice; it seems likely that it is in fact correct, so, that not all of the Recommended Security Headers are currently being set on your site yet. You can test the site with a tool like SecurityHeaders.com, to see which ones are still missing from your configuration.

Kind regards, Jarno

Hi @davidoso,

Fair question, can’t say I know exactly why that might’ve happened here. In any case, your User and the “Reset” button for 2FA might not appear when you still have the define( 'RSSSL_DISABLE_2FA', true ); in your wp-config.php file.

So after logging in to the WP Dashboard, remove the line from your wp-config.php; then navigate to Security -> Settings -> Login Protection -> Two-Factor Authentication -> Users once more, refresh the page once, and check if the Reset button now appears for your user account.

After which you could set the desired user roles only in the “Enable for” field, but skip adding these within the “Enforce for” field; so that no grace period will be required to configure 2FA, and no lock-out should be able to occur any longer either.

Kind regards, Jarno

Hi @loudfan,

Please know that you can dismiss these notices in the Free plugin as well, by enabling the “Dismiss all notifications” setting under Security -> Settings -> General in the plugin.

Additionally, the severity of these items will be adjusted to “Recommended” instead of “Critical” in an upcoming release.

Hope this helps, but let me know if you have any further questions about that.

Kind regards, Jarno

Hi @davidoso,

Thanks for sharing the message. I would still suspect that this particular account is locked out due to the Grace Period having expired.

What I would suggest to confirm if this is indeed the case:

– Re-enable the 2FA feature and after doing so, navigate to Settings -> Hardening -> Basic and disable the “Prevent login feedback” slider.

– Log out and try logging into the account that experienced the issue, and you should now see the actual reason why you can’t login

If it was indeed due to the Grace Period having expired, you could remove the “Administrator” role from the “Enforced For” field in the 2FA settings, so that 2FA is enabled but not required for those users. This will avoid the account being locked out if the Grace Period expires, effectively making 2FA optional.

Kind regards, Jarno

Hi @bpahe,

Thank you for your honest review and feedback, we really do appreciate it.

If you solely intend to use the plugin to enforce HTTPS on your site, and don’t wish to be notified about other security recommendations via the Site Health menu; you can dismiss all of these Site Health notifications by activating the Dismiss all notifications slider under Security -> Settings -> General.

With regards to added functionality between Free and Pro, please know that there are 11 hardening settings available in the Free version of the plugin as well (located under Security -> Settings -> Hardening -> Basic), as well as Two-Factor Authentication (E-mail) which is also included with this Free plugin.

If you have any further questions or concerns about this, let me know as well.

Kind regards, Jarno

• This reply was modified 1 month ago by jarnovos.

Hi @davidoso,

What was the exact behavior that occurred when the login was prevented, did you not get the input field for the 2FA code presented at all when logging in to that account?

If this is the case, the most-likely explanation is that 2FA was require for that user role; but the Grace Period for the user to configure 2FA had expired. And the login was blocked as a result.

Now that you’re logged into the Admin Dashboard again, you can remove the define( 'RSSSL_DISABLE_2FA', true ); from the wp-config.php file and check under Security -> Settings -> Login Protection -> Two Factor Authentication -> Users if the 2FA status for the account in question had indeed “Expired”.

If this is the case, you can click Reset to restart the Grace Period and configure 2FA on the next login attempt. If you’d rather make 2FA optional (so, don’t lock the account if 2FA isn’t configured within the grace period) you can remove this User Role from the Enforced for section.

Kind regards, Jarno

Hello @manni65929,

These Site Health notices are purely for your information; to indicate the configuration recommended by the plugin. But of course they can be disabled.

– The notices will no longer appear if you already have the relevant functionality enabled in a different plugin, e.g., the 2FA/Firewall notices will no longer be displayed if you have a plugin like WordFence enabled.

– You can also prevent being notified about these functionalities, even if you don’t have another plugin handling this already, by enabling the Dismiss all notifications setting under Security -> Settings -> General.

Kind regards, Jarno

No problem at all @cke11y, glad I could assist here.

Just let me know if you have any further questions about the plugin.

Kind regards, Jarno

Hi @cke11y,

Great, I see that your site now works correctly over HTTPS/SSL!

You will be prompted by the plugin to renew your certificate prior to it’s expiration, so you can renew & install a valid SSL certificate once more. This will work in the same way as you’ve done now.

Kind regards, Jarno

Hi @cke11y,

Your screenshot displays that you have a Sectigo SSL certificate installed, so that’s not an SSL certificate generated by this plugin. This plugin only generates Let’s Encrypt SSL certificates.

If all steps have been completed during the Let’s Encrypt Wizard, you will be presented with three files upon reaching the final step of the Wizard.

These three files combined are your newly generated Let’s Encrypt SSL certificate, which you can then install in your Hosting Control Panel (e.g., cPanel, Plesk) to secure the site with SSL (instruction articles attached below).

Installing an SSL certificate in cPanel: https://really-simple-ssl.com/installing-ssl-on-cpanel/

Installing an SSL certificate in Plesk: https://really-simple-ssl.com/installing-an-ssl-certificate-on-plesk/

Kind regards, Jarno

Hi @cke11y,

Your first screenshot is still displaying the “Directories” step, so you would want to switch to the “DNS Verification” method by clicking the button; this will bring you to a set of alternative steps which involve adding a TXT record in your DNS management settings.

Keep in mind: it can take some time for the newly added DNS record to fully propagate.

EDIT: Your second screenshot does show the correct method, but you should not click Save and Continue before completing this particular step. Instead, click Refresh and follow the instructions. Only when all steps have been completed should you proceed to the next page.

Kind regards, Jarno

• This reply was modified 1 month, 1 week ago by jarnovos.

Hi @cke11y,

This message means that the Permissions Check did not succeed due to some limitation on your environment, so you can’t proceed with the Directory method in the Let’s Encrypt Wizard because of it. From our end, we unfortunately can’t affect the limitations on your server that might prevent the certificate generation from succeeding.

You can try switching to the DNS Verification method instead, which allows you to verify domain ownership in an alternative way; by adding a TXT record in the DNS management settings of your Hosting Provider.

You might need to use the “Reset Let’s Encrypt” link in the top right corner of the Wizard once after switching to the DNS Verification method, if the certificate generation doesn’t succeed the first time around.

Kind regards, Jarno

Hello @phoenix26,

I came across another user experiencing this issue a few weeks ago (reference).

This behavior indeed occurs when the Referrer Policy is set to no-referrer as this drops the “HTTP_REFERER” value, and the code in wp-login.php that relies on it is therefore affected as well.

Since using the no-referrer value for the Referrer Policy causes this issue, you may want to consider using strict-origin-when-cross-origin instead (which is also the browser default: https://web.dev/articles/referrer-best-practices#default).

I hope that these insights are useful to you.

Kind regards, Jarno

Hi @swcomm,

Rest assured; the plugin still contains the same SSL functionality that it always had.

If you had previously enabled other functionality that you now wish to disable, you can deactivate those under Security -> Settings, where you will also find the Login Protection tab. The Firewall is part of the Pro plugin, so assuming you’re using the Free version of the plugin, no additional steps are needed to disable it.

Kind regards, Jarno

Hi @letoniusz,

As mentioned in my post above, using the Deactivate and use HTTP option reverts all of the mentioned changes in order to move the site back to https://.

Kind regards, Jarno