Configuring your WordPress installation to work over HTTPS is no longer optional - it’s an absolute must-have. Allowing visitors to access your website over an encrypted connection brings not only security improvements, but it’s also crucial for your SEO as search engines penalize sites that don’t have an SSL certificate. Yet, the process of obtaining an SSL certificate, installing it on your hosting account, and then configuring WordPress to use it is not as straightforward as it may seem.
Our support team here at ICDSoft is contacted by customers on a daily basis with those exact problems - “Not secure” messages, redirect loops, mixed content warnings, pages that have a broken layout or missing resources. Quite often, all of these issues are attributed to various SSL problems. So in this guide, we will explain why they happen, and what needs to be done, step-by-step, in order to resolve them. Regardless of your WordPress experience level and where you are hosted, this guide will help you get your website fully secure, fully functional, and recognized by all browsers.
So without further ado, let’s take a deep dive into the world of WordPress and SSL certificates and how to fix the most common errors for good.
1. "Your Connection is not private" (No SSL Installed)
This issue has different names depending on the browser, but the common thread is the "Not secure" warning shown next to the domain in the address bar of the browser. Google Chrome will report an error saying "Your connection is not private". Firefox is a bit more intimidating with a "Potential Security Risk Ahead" message. Safari would warn you that the "website has a certificate that is invalid" ("This Connection Is Not Private").
Regardless of what the wording is, the culprit here is the lack of an SSL certificate covering your domain when trying to access the website over HTTPS. In order to establish an HTTPS connection, there must be an SSL certificate installed for your domain at the web server handling requests for your site.
To resolve the problem, you need to obtain an SSL certificate for your domain name and then have it installed on your web server. Most hosting companies nowadays provide the option to install an SSL certificate from their control panel. Here at ICDSoft, all hosting plans come with free SSL certificates from Let's Encrypt. You could also order a commercial SSL from the ICDSoft Account Panel.
If your web host does not offer you the option to get an SSL certificate through their system, you could consider using one of the publicly available trusted Certificate Authorities and services, such as Let's Encrypt, ZeroSSL, or Buypass Go SSL. All these CAs provide free, widely supported certificates with one small caveat. The main downside is that all these CAs offer "short-lived" certificates, which typically expire in 90 days. This means that you will manually have to renew and re-install the certificate every 90 days.
Of course, the other option is to purchase a commercial SSL certificate from one of the many vendors out there, such as DigiCert, Sectigo, GeoTrust, Thawte. The current advantage is that these commercial certificates have a longer validity period of one full year - 365 days. This takes away the hassle of having to worry about renewing it once every 90 days. However, that's all about to change as the CA/Browser Forum recently passed a ballot to reduce SSL/TLS certificates to 47 day maximum term by 2029, endorsed by Sectigo.
The newly approved measure, initially proposed by Apple and endorsed by Sectigo in January 2025, will gradually reduce certificate lifespans from the current 398 days to 47 days through a phased approach:
- March 15, 2026: Maximum TLS certificate lifespan shrinks to 200 days. This accommodates a six-month renewal cadence. The Domain Control Validation (DCV) reuse period reduces to 200 days.
- March 15, 2027: Maximum TLS certificate lifespan shrinks to 100 days. This accommodates a three-month renewal cadence. The DCV reuse period reduces to 100 days.
- March 15, 2029: Maximum TLS certificate lifespan shrinks to 47 days. This accommodates a one-month renewal cadence. The DCV reuse period reduces to 10 days.
🔒Automated Let’s Encrypt Renewal: Built into Every ICDSoft Account
At ICDSoft, we have resolved this problem with an automated system that renews Let's Encrypt certificates for our users. As long as your hosting account is active and your domain is pointed here, you won't have to worry about renewing the free Let's Encrypt certificates that come with our service.
To resolve the "Note secure" error, you need to install an SSL certificate for your domain, and ICDSoft users can easily do that from the Control Panel > HTTPS/SSL section > Let's Encrypt certificates. There, if your domain uses the DNS service of the hosting account, you will have the option to activate a wildcard SSL covering all your subdomains (e.g. *.example.com). Otherwise, you will have to activate a Let's Encrypt certificate for the specific hostname. Note that you should make sure that both your root domain (example.com) and the www subdomain (www.example.com) are pointed to our server’s IP address. You can see the server's IP address listed on the right side under System Information. In case you are having problems obtaining the certificate, don't hesitate to contact our support team.
2. Fixing the "Not Secure" Warning When SSL is Active
There are also a lot of cases where a customer would have an active SSL certificate installed for their domain, but accessing the website would still result in a "Not secure" warning in the address bar of the browser. Typically, this happens because WordPress is not configured to use the certificate. If you look closely, you would notice that the website is being loaded over plain HTTP, instead of HTTPS.
http://, which results in a "Not Secure" warning shown at the address bar of the browser.To resolve this problem, you would have to change the WordPress Address (URL) and Site Address (URL) to use "https://". In our case, these values would have to be changed from http://icdsoft-store-demo.com to https://icdsoft-store-demo.com. WordPress administrators can easily do that via the dashboard > Settings > General.
However, there are a lot of cases where this change alone would not be sufficient. Besides those two addresses, there could be hundreds and even thousands of URLs in the WordPress database that would also have to be updated from "http://" to "https://".
The most efficient way of updating all URL instances containing your website's address from HTTP to HTTPS is to use WordPress's command line interface, also known as WP-CLI. The tool has a special command for this task called wp search-replace. It goes through the entire database and updates all instances it finds. To use WP-CLI, you would have to connect to your account over SSH. Once you've connected, you should navigate to the folder containing your WordPress installation, and run the following command:
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guidYou should replace example.com with your actual domain name. The first parameter is our search criteria (find all occurrences of "http://example.com") and the second one is the new value it should be applied (replace them with "https://example.com"). It's important to note if your website is configured with or without the "www." prefix. If your website has been configured to work over "http://www.example.com", then that should be your search criteria (the first parameter). Otherwise, there won't be any matches and the command will not produce any results.
The --skip-columns=guid parameter tells WP-CLI not to modify the guid column in the wp_posts table, because GUIDs are supposed to remain permanent identifiers and should not be changed even when switching to HTTPS.
Our new Control Panel (v3) has a built-in Web SSH Terminal, which you can use to easily connect to your account over SSH and run such commands.
ICDSoft customers have one other handy tool they can use to get this job done. Instead of running such commands manually, they can use the WordPress Manager available in the Control Panel to easily run a database-wide search and replace to update all instances from "http://" to "https://" with just a few clicks. The tool essentially runs that same wp search-replace WP-CLI command for you. Some users are not comfortable executing such SSH commands, and they find the web interface much easier to work with.
To use it, go to the WordPress Manager and press the Manage button next to the installation in question. There, click on the pencil icon next to the URL (which should be set to "http://example.com"), and enable the option "Use HTTPS in the WordPress URL" on the window that will pop up. The URL preview should be changed to "https://example.com". All you would have to do is press the Save button and let the WordPress Manager work its magic. The tool will also generate a temporary backup of your installation the way it was prior to the change, so you can easily restore from it if something goes wrong.
Once you've applied this change, all requests for your domain would be redirected to their corresponding https:// version. In other words, even if you access a given page on the site via plain http://, your request would be redirected to https://, and the "Not Secure" warning would no longer be shown.
3. Mixed Content Errors in WordPress
The other common problem with WordPress and HTTPS are the mixed content errors. Quite often, users will reach out to us saying their website's formatting and layout got completely obliterated after activating an SSL certificate and switching WordPress to work over HTTPS. Upon investigating, our support members usually find mixed content errors in the browser console (we will get to that in the next segment):
about/:1 Mixed Content: The page at 'https://icdsoft-store-demo.com/about/' was loaded over HTTPS, but requested an insecure element 'http://icdsoft-store-demo.com/wp-content/uploads/2020/02/organic-products.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.htmlUnderstand this warning
about/:1 Mixed Content: The page at 'https://icdsoft-store-demo.com/about/' was loaded over HTTPS, but requested an insecure element 'http://icdsoft-store-demo.com/wp-content/uploads/2020/04/organic-store-logo5.svg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.htmlSuch errors indicate that there are resources on the web page that are being loaded over a plain HTTP connection while you are trying to access the website securely over HTTPS. To avoid such errors, all elements on your pages (including JavaScript and CSS files, as well as images) would have to be loaded securely over HTTPS.
The wp search-replace command we just covered should in theory take care of all that since it goes through the database and updates all URLs to work over https://. However, there are some WordPress themes and plugins that contain hard-coded URLs that could be HTTP, so they would not be fixed by running the wp search-replace command. So instead of having to go through the hustle of identifying and updating those elements one-by-one, you could apply a much easier fix. The solution is to add a single directive to the .htaccess file in your WordPress folder:
Header always set Content-Security-Policy: upgrade-insecure-requestsThis directive tells the browser that if there are any resources on the page (images, scripts, CSS, JS, etc.) that use http://, to automatically switch them to https:// before loading them. In other words, it converts insecure requests to secure. You should add it at the top of your .htaccess file, on a new line, before all other directives.
Again, ICDSoft customers are spared from having to manually apply such changes. The option to Use HTTPS in the WordPress URL at the WordPress Manager adds this line automatically to the .htaccess file as part of the procedure.
4. Troubleshooting SSL Errors with WordPress
If you've covered all three steps we've outlined thus far, then you shouldn't really need to troubleshoot any SSL errors on your WordPress installation. Your website should be fully secure, and all visitors should be able to access it over HTTPS without any errors or warnings. Yet, you might want to verify that everything works correctly. Or, if you are not fortunate enough to be hosted at ICDSoft (which you can always change by requesting a free migration of your site), then you might have to dig into these errors on your own. So here is a quick troubleshooting list for debugging WordPress SSL errors.
4.1 Disable all caching mechanisms
If you've installed an SSL certificate for your website, and you've switched WordPress to work over https://, but you are still getting a "Not Secure" warning when accessing your site, the first thing to do is clear all the available caching mechanisms:
- Clear your browser's cache - the caching could be at your web browser, so make sure to fully clear it, or you could try loading your site in an incognito mode.
- Clear any server-side caching - most hosts nowadays provide some type of server-side caching, so that might have to be cleared too. At ICDSoft, this could be done via the Control Panel > Server-side Caching section.
- Caching plugins - if you are using a caching plugin on your WordPress installation, such as Litespeed, WP Rocket, or W3 Total Cache, you might have to clear its cache as well.
4.2 Check the browser console
The browser console can come quite handy when troubleshooting SSL-related problems with WordPress. As we showed you earlier, it could reveal the reason for a broken page layout or missing images and other resources, due to mixed content errors. If you've activated HTTPS on your WordPress website, and you start having some problems, the first thing you should do (after clearing all the available caching mechanisms) is to check the browser console for errors.
If you are on Windows or Linux, you would be able to open the browser console in most browsers (Chrome, Edge, Firefox) by pressing Ctrl + Shift + J. For macOS with Safari, you should use Cmd + Option + J.
Once you've opened the browser console, make sure to reload the page and then check for possible mixed content errors.
4.3 Use a third-party website
Whenever you are in doubt, it's always a good idea to use a third-party tool to confirm the results. This would exclude any local caching issues you might have, and it would also check for mixed content errors.
Why No Padlock? is a simple yet effective tool that will tell you about any insecure items on your SSL page. You just have to enter the full https:// URL of your page, and you will get a complete SSL report.
5. Why SSL Plugins Are Often Unnecessary (and Can Cause Issues)
It's common WordPress knowledge that the fewer plugins a site has, the better. Having too many plugins can slow down your site, and sometimes they can bring a lot of unexpected problems as some plugins can interfere with one another. So if you can get something done without using a plugin, then it's usually a really good idea to do it.
As with most things with WordPress, there is a plugin for just about everything. Perhaps the most popular plugin for WordPress and SSL is Really Simple Security (formerly known as Really Simple SSL). By definition, this plugin "Migrates your website to HTTPS and enforces SSL in just one click." However, in our experience as a support team at ICDSoft, this particular plugin tends to do more damage than good. We've had a lot of cases where Really Simple Security would cause redirect loops on a website, or it would interfere with the operation of other plugins. For example, a customer would complain that a given feature on their site is not working as expected, and after going through a tedious debugging process, we finally start disabling plugins one by one until we find out that it's actually Really Simple Security that's causing the issue and deactivating it is the solution.
In such cases, what we do is to deactivate the Really Simple Security plugin and also use the option to remove all its directives from the .htaccess file. Applying the Use HTTPS in the WordPress URL option in the WordPress Manager at the Control Panel is usually enough to make the site fully secure.
Of course, we have nothing personal against that particular plugin, and we are only speaking from experience.
Conclusion
If you follow the steps we've described here, then your WordPress should load up over a fully secure HTTPS connection, without any errors, and without needing an additional plugin for this task. The first step is to obtain an actual SSL certificate covering your website's hostname, and then you should configure WordPress to work over https://. If you do encounter any errors along the way, make sure to follow our troubleshooting guide here or contact our support team for help, and see just how fast we will get your WordPress website to load over an encrypted connection.
