I am running a WordPress site on Ubuntu VM as a reverse proxy (URL rewrite) behind an internet-facing IIS windows server. The site works fine with HTTP. No issues.
However, been having a few issues with HTTPS / SSL configuration. The SSL certificate is attached to the domain name on IIS on the internet-facing windows server while the site is served by Linux VM.
After changing it to https, if I change the site URL in WordPress settings page to https from HTTP, the site does not work and I get a “too many redirects” or “page not redirecting properly” error (in the browser if you open developer tools, you can see the site reloading and looping but no output on screen).
If I leave the siteurl in settings as HTTP domain(dot)com, site loads and PHP works but no scripts or JS files are loaded by the browser, and the error is “Blocked loading mixed active content by firefox HTTP domain(dot)com/some/script/CSS” because the siteurl is still HTTP and not https.
I have also tried to change the site URL for specific files in .htaccess and wp-config file and functions page and get different errors.
It is most likely due to termination of SSL. WorldPress doesn't handle proxies all that well. So you may need to add a bit of code to wp-config file.
Open file and find:
define('WP_DEBUG', false);
Add:
if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )
{
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}
You have to run WordPress on that Ubuntu VM under HTTPS, in order to break from endless HTTP->HTTPS redirection.
Currently WordPress decides to redirect, because it detects that only HTTP requests are coming,
Browser ---HTTPS--> IIS ARR ---HTTP--> WordPress
It only stops redirection if you get
Browser ---HTTPS--> IIS ARR ---HTTPS--> WordPress
Related
I'm an amateur here. So my blog set up is:
Root site on one droplet: example.com, SSL via Let's Encrypt
Ghost blog hosted as subdirectory, i.e. example.com/blog, on a separate droplet
On main server's Nginx config, location /blog/ is directed the blog server's IP and port 2368 via proxy pass
It was working for quite a while until it is not 😅 Somehow the Ghost config file corrupted (completely emptied), and Ghost could not run. As it was still on Ghost 3, so decided to do a clean migration on a new one-click droplet with Ghost 5.
I had all posts exported before and Ghost/content/images all backed up.
The new site imported content seems fine. But I could not get the HTTPS working. The root site is on HTTPS and loads the blog page fine, but all posts are requesting images via http - which won't work and gives Mixed Content error. Something like:
Mixed Content: The page at 'https://www.example.com/blog/post-title/' was loaded over HTTPS, but requested an insecure image 'http://www.example.com/blog/content/images/size/route-to-image.jpg'. This request has been blocked; the content must be served over HTTPS.
Any idea? I also noticed that after migration I have to proxy pass to just the IP rather than IP + port 2368 to actually make the site work.
I have tried Ghost setup SSL but it gave errors.
In Ghost admin panel, all images show up fine even it's still requesting via http.
I'm suppsed to move to docker (docker-compose) a wordpress site that already works "correctly" in cPanel. I say "correctly" as the "site url" and "wordpress site url" both report http:// rather that https.
In the cPanel setup you can visit http or https and any internal link to js and css use https. After moving to docker behind traefik load balancer I get the page with all links using http. That clearly breaks security and the site is unusable.
What's the mechanism used to build up the links to assets? does it use some variables that can be set differently? My docker has apache and I'm using the same .htaccess (at least I'm using what is in the cPanel's backup...).
If I force to https, /wp-admin becomes unreachable... Currently traefik serves correclty resources requested using both http and https.
EDIT: adding
$_SERVER['HTTPS']='on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);
does turn most internal links to https, but /wp-admin becomes unreachable ("you're not allowed to visit thie page"). As an example it loads /wp-includes/js/jquery/jquery.js via http.
Why the
Any hint is appreciated...
I use ngrok for tunnelling to my localhost, and the only way I could successfully run my environment over proxied https is by converting wordpress permalink url's to relative urls using...
https://wordpress.org/plugins/relative-url/
The plugin is 2 years out of date but still does the job fine and allows my tunnelling to my localhost to run over https. Handy for localhost https endpoint access (without force define home/urls in wp-config.php)
I solved it rearranging the order of the settings in wp-config.php.
wp-configi.php is not just a configuration file as the name suggests. You need to set _SERVER['HTTP'] before the last line:
$_SERVER["HTTPS"] = "on";
require_once(ABSPATH . 'wp-settings.php');
(thanks to my friend Dario for the help).
I have a VPS on which I serve my domain and where I have all the WordPress installation files. The domain is served with SSL over CloudFlare.
Problem is that the markup inside the installation files does not use https for stylesheets, JS files, etc. They are always served over http and Google or WordPress docs do not help with solving this issue. With this being said, the installation layout looks pretty ugly without any loaded stylesheet whatsoever, or JS functionality.
I certainly doubt that .htaccess rewrites would help with this.
How do you enforce WordPress installation over HTTPS?
(This is how the markup actually looks like, and see the URL in the address bar)
if your web server is running Nginx, you can easily redirect all of your HTTP traffic to HTTPS by adding the following code to your Nginx config file. This is the recommended method for redirecting WordPress running on Nginx.
server { listen 80;server_name domain.com www.domain.com;xamplereturn 301[https://ez.com$request_uri][1];}
The admin side of my wordpress site is stuck in HTTPS and very slow as a result.
I am trying to set the admin to HTTP.
Here is my setup and what I've tried so far.
Godaddy VPS with Godaddy SSL certificate
In wp-config.php I have: define( 'FORCE_SSL_ADMIN', false );
Tried installing the wordpress-https plugin. The admin https checkbox is greyed out / disabled.
Here are the settings on that plugin.
Check httpd.conf and htaccess files for any rewrites - none found.
Server does have Vernish installed - asked Godaddy support to check for any relevant configs in Varnish. None found.
I have tried commenting out code in wp-includes/functions.php based on suggestion here (see comment by user joelbair).
I always flush caches, and sometimes reboot the VPS completely after making changes.
Any suggestions?
Could it be related to SSL signing certificates or how SSL was installed on the server initially?
Was the HTTPS server sending the Strict-Transport-Security header? If so, your browser received instructions to always use HTTPS version of the site. Try opening the HTTP version in another browser, or try clearing your browser cache in an attempt to remove that header's control.
Install WordPress Force HTTPS plugin.
Change you're WordPress Address (URL) and Site Address (URL) in General Setting to https://yoursite.domain
Clear browser cache
No configuration needed.
On a Drupal 6 site we can't figure out why pages, other than the home page, refuse to be accessed in https. Accessing any page on the site, except the home page, immediately redirects back to itself at http.
Apache is correctly setup with a valid SSL certificate.
I'm certain its not the .htaccess file. There's no rewrite rules regarding https or port 443.
I added $conf['https'] = TRUE; to the settings.php
I installed the Secure Page module and configured it to secure the page we want, but it causes a redirection loop ending in a browser error.
No other modules that I can see relate to http vs. https
I can't find any admin settings regarding the base URL that would force this behavior.
I have a lot of experience with server admin, LAMP software, and a little with Drupal, but this one has me stumped. Any hints or suggestions would help me a lot.
Check to see if base url in settings.php is set to the http address. This can cause this behavior.