So, we have a service that is behind a load balancer, and we are offloading SSL at the load balancer. The WSDL shown when we go to https://example.com/Service.svc?wsdl shows http://example.com/Service.svc and http://example.com/Service.svc?wsdl=wsdl0. Is there a way to change what the WSDL shows so that all of the URLs are https instead of http?
Related
I have a GCP instance group with 2 instances. Both are up and running. I want to configure a load balancer (HTTPS) to manage the traffic.
I've set up a forwarding rule with the HTTP-protocol and a certificate managed by google. This all works, but only when the traffic between the load balancer and the backend (the instances) is plain HTTP.
Steps I did so far
I create a template and this template is just a normal N1 series machine. I checked the boxes to create firewall rules for allowing http and https traffic.
I create a firewall rule named "allow-ports". This firewall rule targets all instances in the network, has a 0.0.0.0/0 IP-range and allow port tcp = 80, 443. How I see this, this firewall rule should open both the http (80) and https (443) port.
I create an instance group with port mapping. "http-port" = 80, "https-port" = 443. I use the template I just created.
When the instance group is created, I check if this is running. With SSH, I get access to the instances and install apache (sudo apt-get install -y apache2) on the both. When navigating to their external IP's in the browser, I see them both.
I create a HTTP(S) load balancer, with the option "From internet to my VMs". For backend configuration, I add a backend service with my instance group, protocol HTTP, named port "http-port". For frontend configuration, I set up the HTTPS protocol, create an IPv4 IP address, create a google-managed ssl certificate, and I'm done. I also added health checks btw.
Now... these steps work (after a few minutes). With the cloud DNS, I have set up a domain name which points to the IP address of the load balancer. When going to , I see the apache page.
What doesn't work?
When I change the backend configuration to HTTPS (and named port "https-port"), I get a 502 server error. So it seems to me that there is some connection, but there is an error. Could this be an apache error?
I have spent a whole day, creating and recreating instance groups, firewall rules, load balancers, ... but nothing seems to work. I'm surely missing something, probably something dumb, but I have no clue what it could be.
What do I want to achieve?
I do not only want a secure (HTTPS) connection between the client and my load balancer, I also want a secure connection between the load balancer and the backend service (the instance group). Because GCP offers the option to use the HTTPS protocol when creating a backend service, I feel that this could be done.
To be honest: I'm reading some articles about the fact that the internal traffic is secured, so a HTTPS connection is not necessary. But that doesn't matter to me, I really want to know how this works!
EDIT
I'm using the correct VPC (default). I also edited the firewall rule from 0.0.0.0/0 to 130.211.0.0/22 and 35.191.0.0/16 (see: https://cloud.google.com/compute/docs/tutorials/globally-autoscaling-a-web-service-on-compute-engine?hl=nl#configure_the_load_balancer).
In addition to my previous comment. I followed your steps at my test project to find out the cause of your issue. I installed the same configuration and checked it with HTTP at the back-end. As it was expected, I found no errors. After that, I installed SSL certificates to the back-end and to the load balancer. Then I switched my back-end, load balancer and health checks to HTTPS and disabled HTTP at the back-end. At this point, I found no errors also.
So, I decided to get 502 error in my test configuration in some way. I switched my health check at the load balancer to HTTP. A few minutes later I tried to reach my test service again and got 502 error. When I switched back my health check to HTTPS 502 error gone away.
During this test, I didn't change firewall rules, but allowed HTTP and HTTPS traffic in my instance template and I used default network.
I am very new to load balancers. I have just set one up that listens on SSL. I also created an EC2 instance and added it to the target group of the "Application Load Balancer". The target group is also connected by SSL.
I have installed apache on the EC2 instance and placed an index.html file in the /var/www/html directory.
I would have thought typing the load balancer associated domain address (www.example.com) would route me to the index.html file of the EC2 instance (which is the only target). However I am getting a Bad Gateway 502 error.
Initially I only had SSH inbound rule on the EC2. I opened up 443 for HTTPS but that didn't make a difference.
Do I need to install a certificate for the SSL on the EC2 as well as the load balancer? And do I need to open any additional ports?
Very new to this all and not sure how the load balancer communicates with the EC2 instance. Hoping that it would be internal so that the EC2 instance was not at all exposed in isolation.
So many things can go wrong here but (assuming that you have correctly configured the load balancer) I think what you have should work if you add HTTP listener to your load balancer, change your target group's protocol to HTTP (because the load balancer talks to the EC2 over HTTP), and then, add something like this to your .htaccess:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule . https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
You can read more here.
Install the SSL certificate on the load balancer instead of the EC2. The EC2 does not need its own SSL certificate.
Here are the steps to add HTTPS to a application load balancer:
When you try to set up HTTPS inbound to the load balancer it will give you a section called "ACM" click into that to get a SSL certificate
The ACM page will give you a section to create a new SSL certificate. You will need to input the domain name and some details, afterwards it will give you a CNAME record. You need to go to your domain's DNS settings to add that new CNAME record.
Once you create a SSL certificate with ACM you'll be able to use that on the load balancer, go back to the HTTPS listener and use that new SSL certificate
Then make sure your load balancer security group allows inbound to 443 port.
After that https should work on the load balancer
Note:
I would only set up https after I get http working first on the load balancer and it is directing to the right ec2.
Since the target group for http and https is the same, you want to make sure the target group is working before messing around with https.
That way you won't have two problems to deal with at the same time (https + incorrectly configured target groups/http). It'll allow to tackle each item step by step.
Hope that helps!
I have an instance listening on port 8080.
I want to create a load balancer to map 443 (ssl) to the instance port 8080 so that ssl terminates at the load balancer and traffic between the lb and the instance is not encrypted.
I have uploaded the ssl cert, created an HTTP load balancer but can't seem to figure out how to set up the forwarding like that.
Coming from AWS ELB, there's a simple way to do this, can't find a way to do it on Google Cloud Platform.
Any thoughts ?
Found it.
Create an instance group that has at least 1 live instance
Create http load balancer with the following:
Upload a SSL certificate
Create a backend service to point to the instance group. Make sure the protocol is HTTP
Create a target https proxy with the certificate you uploaded
Finally, create a global forwarding rule that points HTTPS to the target proxy you created before.
We have website e.g. http://www.acb.com which points to a hardware load-balancer which is suppose to load-balance two dedicated server. Each server is running apache as a frontend and uses mod_proxy to forward request to tomcat.
Some pages of our website require SSL like https://www.abc.com/login or https://www.abc.com/checkout
SSL is terminated at hardware load-balancer.
When I configured mod_pagespeed it compressed, minimized and merged css file and rewrote them with an absolute url http://www.abc.com/css/merged.pagespeedxxx.css instead of relative url /css/merged.pagespeedxxx.css.
It works fine for non ssl pages but when I navigate to an ssl page such as https://www.abc.com/login all the css and js files are blocked by browser like chrome as their absolute url is not using ssl.
How can I resolve this issue ?
Check for https string in this documentation and this one.
You should show us in your question your current ModPagespeedMapOriginDomain && ModPagespeedDomain settings.
From what I understand from these lines:
The origin_specified_in_html can specify https but the origin_to_fetch_from can only specify http, e.g.
ModPagespeedMapOriginDomain http://localhost https://www.example.com
This directive lets the server accept https requests for www.example.com without requiring a SSL certificate to fetch resources - in fact, this is the only way mod_pagespeed can service https requests as currently it cannot use https to fetch resources. For example, given the above mapping, and assuming Apache is configured for https support, mod_pagespeed will fetch and optimize resources accessed using https://www.example.com, fetching the resources from http://localhost, which can be the same Apache process or a different server process.
And these ones:
mod_pagespeed offers limited support for sites that serve content through https. There are two mechanisms through which mod_pagespeed can be configured to serve https requests:
Use ModPagespeedMapOriginDomain to map the https domain to an http domain.
Use ModPagespeedLoadFromFile to map a locally available directory to the https domain.
The solution would be something like that (or the one with ModPagespeedLoadFromFile)
ModPagespeedMapOriginDomain http://localhost https://www.example.com
BUT, the real problem for you is that apache does not directly receive the HTTPS requests as the hardware load balancer handle it on his own. So the mod-pagespeed output filter does not even know it was requested for an SSL domain. And when it modify the HTML content, applying domain rewrite maybe, it cannot handle the https case.
So... one solution (untested) would be using another virtualhost on the apache server, still HTTP if you want, dedicated to https handling. All https related urls (/login,/checkout,...) would then be redirected to this specific domain name by the hardware load balancer. Let's say http://secure.acb.com. This name is only in use between the load balancer and front apaches (and quite certainly apache should restrict access to this VH to the load balancer only).
Then in these http://secure.acb.com virtualhosts mod_pagespeed would be configured to externally rewrite domains to https://www.example.com. Something like:
ModPagespeedMapOriginDomain http://secure.example.com https://www.example.com
Finally the end user request is https://www.example.com/login, the load balancer manages HTTPS, talk to apache with http://secure.example.com, and page results contains only references to https://www.example.com/* assets. Now when theses assets are requested with an https domain request you still have the problem of serving theses assets. So the hardware load balancer should allow all theses assets url in the https domain and send them to the http://secure.abc.com virtualhosts (or any other static VH).
This sounds like you configured the rewritten URL as http://www.abc.com/css/merged.pagespeedxxx.css yourself - therefor: Try to use a protocol-relative URL, e.g. remove http: and just state //www.abc.com/css/merged.pagespeedxxx.css - this will use the same protocol as the embedding page was requested in.
One of the well standardized but relatively unknown features of URLs
If I get an ssl certificate - can I still access my web pages using http (instead of https) so they'll load faster?
Or perhaps have the ssl for only certain pages on my site? (I'm using web hosting, perhaps it matters.)
Yes. When you're setting up the certificate, you can configure your server to listen on port 443 (for SSL, where it will serve your certificate) as well as port 80 (where normal HTTP traffic will go). For pages where you absolutely want to have SSL, you'll need to force the user to visit the https:// URL.