here is my setup. I have 4 servers
ARR
Node1
Node2
Node3
I have set the nodes up to use a shared configuration and have set the ARR box up to have a central certificate store ( followed the docs on msdn ). On the ARR box there is a DefaultWebsite as per the standard IIS installation. It has a binding that matches all HTTP traffic ( ie no domain specified ). There is also a ARR rule ( set up by default ) that points all requests to my server farm. Everything is working perfectly for normal HTTP traffic, but when I try HTTPS the requests fail ( browser gives ERR_CONNECTION ). I have stuck to all the defaults an no joy. I have multiple sites with multiple certificates, so I have made sure that all HTTPS bindings on the node are set to use SNI and the CCS. Still HTTPS does not work. However, if I add the HTTPS binding on the ARR box, then the requests go through correctly.
Surely that behavior is not correct? I can't manage https bindings on the ARR box and then all other bindings through a shared config setup? I was under the impression that the ARR box should not even need to have a single site configured, it should simply pick up the request, match the ARR rule and then delegate off to one of the nodes?
Am I missing something here, any help would be greatly appreciated
I think it might have something to do with SSL offloading. When I disable that, I get an error 502 response.
Could it have something to do with compression? I zip all responses using a filter, but surely then even http traffic would fail?
so things always look better in the morning. After a couple hours of googling and several re-installs of IIS I finally found the issue. I had deleted the "Default Website". Then in order to get ARR back up I added back a default website. This allowed all wildcard HTTP traffic through to the server farm. When I tried to add a default HTTPS binding however, the IIS config management console forces you to put in a domain name, which doesn't work if you want a "default" implementation.
So to get around this, I simple manually edited the applicationHost.config file and removed the domain name from the binding entry :
<binding protocol="https" bindingInformation="*:443:" sslFlags="3" />
and that's it....happiness!
I had that error too while migrating a single proxy configuration with multi-sites to a ccs + shared config server.
It happens that the default web site configuration did not import correctly and the https binding did not have a certificate assigned.
I assigned a certificate and the error went away.
Related
I am trying to set custom domain for my Firebase app.
Firebase hosted url : https://inventory-app-726af.firebaseapp.com/
Custom Domain: inv.agsft.com
I have followed all instructions as part of setting custom domain but after verification step when I click on finish button, status will always be "Needs Setup".
I am managing DNS through cloudflare (https://www.cloudflare.com/) and I am following Quick setup option.
Any pointers to resolve it?
I had the same problem, I was able to resolve it by toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records
It started working right away.
The proper solution, ie without disabling Cloudflare for the site, is to use Full SSL for your domain/subdomain.
You can either choose Full SSL for all your domain entries, or set up a Page Rule for a specific subdomain, in your case, use "inv.agsft.com/*"
Source: https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3, which in turn points to https://support.cloudflare.com/hc/en-us/articles/115000219871-Why-does-Flexible-SSL-cause-a-redirect-loop-
Had the same issue and this solved the redirect issue. Firebase will however still report the domain as "Needs setup", for that I have no solution, but it does not affect the functionality of the hosting.
For the people that is using Namecheap, This configuration worked for me.
To avoid any kind of ssl issues when using firebase hosting and cloudflare you have to check to following points:
You don't need to toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records unless you don't want the cloudflare ssl certificates and want to just use the firebase ssl certificates (look to this carefully because you will loose the protection that cloudflare provides to your site in case you decide to use only the clouflare DNS)
If you "keep the cloud orange" it will not causes any problem to your firebase hosting.
Add the firebase IP's to cloudflare following the instructions provided by firebase hosting and remove any other A record from your domain/subdomain that you are setting up
To ensure you have a end-to-end encryption (using both firebase ssl as well as cloudflare ssl), make sure that your cloudflare crypto options is set to "Full":
Use a page rule likes in case that you want your root domain to receive all trafic:
In your firebase hosting setup, do the same:
p.s: Look that the message "Needs setup" is still there but the app is running without any problem.
p.s2: the majority problems regarding cloudflare and firebase is that firebase ssl can take several hours to start to work and you keep seeing a message like "your connection is not private". It happens not beucase cloudflare is messing our proxy out but because firebase ssl is still not fully propagated.
I hope it help others :)
In my case I did the same that Brennen did:
toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records.
But just start working when I:
Delete the domain from firebase. (click on the : points select delete domain)
refresh the firebase site
Added again in Quick Setup. I already had the A record added in Cloudflare so I didn't added again.
After that automatically the status added was connected.
Remember: Before testing, clean your browser cache.
When I run dig -t txt +noall +answer inv.agsft.com there are no TXT records showing. Since those are required to verify your ownership of the domain, Firebase Hosting will not continue the setup beyond step one.
Update: since the next step requires you to map A records to the IP addresses of Firebase hosting, I ran the relevant dig too:
$ dig -t a +noall +answer inv.agsft.com
inv.agsft.com. 299 IN A 104.18.56.240
inv.agsft.com. 299 IN A 104.18.57.240
Those are not the addresses I'd expect for Firebase Hosting, so it looks like either you haven't correctly entered the A records, or they have't propagated yet.
When I change my setting like below, it started to work again.
Redirect loop fixed:
For GoDaddy this adding the following solved it for me:
TYPE:A
NAME:#
VALUE: your ip_1
TYPE:A
NAME:#
VALUE: your ip_2
June 2020
Just wanted to share what was successful for me. It was a combination Brennen and Lisbel's answer.
Step 1: Toggle off your DNS status to get a grey cloud (as shown in the earlier answer)
Step 2: Delete the domain from firebase
Step 3: Add it back with Quick Steup
It should be connected after these steps!
I had the same issue. Here's how I fixed it:
1) Cick the View button on the problematic domain (in the Hosting section next to where it says Needs Setup).
2) Change the 'Setup mode' from Quick Setup to Advanced and follow the 3 steps
2a) Open your domain provider's settings (I'm using Google Domains) and add the TXT record it's giving you.
2b) Wait about 4-12 hours for verification
2c) Add the provided A records into your domain provider's settings
This is not a quick process, but it should be working about 5 minutes after you complete step 2c.
Toggling DNS mode didn't work for me. So I tried following approach and it worked for me.
Add CNAME record pointing to {firebase-project}.firebaseapp.com or {firebase-project}.web.app, you could add A record and try.
ADD TXT record as firebase ask you
Verify from firebase (this will show as needs setup, also it didn't go away although this worked)
If new domain/subdomain doesn't works check your browser developer tools network tab. If there are lots of 301 happening then go to cloudflare page rules. Add newdomain.com/* or subdomain.newdomain.com/* then add settings select SSL and set it to full as follows.
Then it will work as expected.
Working as of 11st May 2022 without need to toggle DNS and HTTP Proxy (CDN).
Steps:
Go to Cloudflare Dashboard.
Select SSL/TLS.
Select Overview.
Select Full option for SSL/TLS encryption mode.
After that, refresh your website that previously have issue to access.
Now the website can access successfully.
I've just installed Sylius to test it for possible production use and integrated Paypal through the payum-gateway.
I'm running Sylius with the included webserver on 127.0.0.1:8080 through a nginx reverse SSL proxy for security reasons and so that it is accessible through a regular URI.
After the PayPal-Payment, I'm forwarded back to the page as it should but instead of the origin-page it sends to 127.0.0.1:8080.
The "Show Shop"-link from the admin-menu did this as well until I changed the server name in the "channel settings".
I figured I have to set the public hostname somewhere else, too, but I cannot figure out where I have to do so.
Grepping for '127.0.0.1' yields a lot of results. For example vendor/sensio/distribution-bundle/Resources/skeleton/web/config.php, but that doesn't seem to be the right place.
I don't know the answer to the original question so I won't delete it in case someone else wants to answer.
I solved this specific problem by not using nginx as a proxy but as the webserver itself and deacitivating the webserver that is shipped with Sylius.
I have set up an Apache Web Server 2.4 to act as a proxy for Apache Tomcat 7, communicating via the AJP protocol (mod_proxy_ajp on the Apache side and an AJP connector on the Tomcat side). Everything works great for basic functionality.
Now, I am looking to set some specific AJP attributes, but can't quite get it to work...
Looking at the mod_proxy_ajp page (http://httpd.apache.org/docs/current/mod/mod_proxy_ajp.html), under the Request Packet Structure section, I see a listing of attributes. These attributes include the likes of remote_user, and ssl_cert (code values 0x03 and 0x07, respectively). There is also an "everything else" attribute called req_attribute with code value 0x0A that can be used to set any arbitrary attribute in an AJP request.
Further, on the same page, under the Environment Variables section, it states the following:
Environment variables whose names have the prefix AJP_ are forwarded to the origin server as AJP request attributes (with the AJP_ prefix removed from the name of the key).
This seems straightforward enough, and indeed, I am easily able to set an arbitrary AJP attribute such as "doug-attribute" by setting an Apache environment variable called "AJP_doug-attribute", and assigning a relevant value. After doing such, I can analyze the traffic using Wireshark, and see the "doug-attribute" field show up in the dissected AJP block, prefixed with a hex value of 0x0A (the "req_attribute" type listed above). So far so good.
Now I want to try to set the ssl_cert attribute. In the same fashion, I set an environment variable called "AJP_ssl_cert". Doing so, it does show up in Wireshark, but with prefix code "0x0A". Further, my Java application that wants to read the "javax.servlet.request.x509certificate" does not find the certificate.
However, I also notice some other attributes in the Wireshark capture that are listed on the website, like ssl_cipher and ssl_key_size. But in the capture, they show up as "SSL-Cipher" and "SSL-Key-Size" (and have the appropriate "0x08" and "0x0B" prefix codes). So, I try setting the cert attribute again, this time as "SSL-Cert", but I get the same results as before.
To compare, I altered the Apache configuration to require client certificates, and then provided one in the browser when visiting the associated web page. At this point, I look at the Wireshark capture, and sure enough, there is now an attribute named "SSL-Cert", with code "0x07", and my web application in Tomcat is successfully able to find the certificate.
Is there any way that I can manually set the attributes listed on the mod_proxy_ajp page, or does the module handle them differently from other arbitrary request attributes (like "doug-attribute")? I feel like there must be something I am missing here.
As some background, the reason that I am trying to do this is that I have a configuration with multiple Apache web servers proxying each other, and then at the end, an Apache web server proxying to a Tomcat instance via AJP. All the Apache web servers use SSL and require client certificates. With just one Apache server, Tomcat can receive the user's certificate just fine without any special configuration on my part. However, with multiple, it ultimately receives the server certificate of the previous Apache proxy (set on that machine using the SSLProxyMachineCertificateFile directive).
What I am hoping to do is place the original user's certificate into the headers of the intermediate proxied requests, and then manually set that certificate in the AJP attributes at the back end so that the web application in Tomcat can read the certificate and use it to perform its authorization stuff (this part is already set in stone, otherwise I would just add the certificate as a header and make the Java app read the header).
EDIT: of course, if there is an easier way to accomplish passing the user's certificate through the proxy chain, I'd be more than happy to hear it! :)
I'm trying to use Liferay for http and https
if I include in portal-ext.properties:
company.security.auth.requires.https=true
web.server.protocol=https
Will be working ok with https but in http is showing incorrect themes due is trying to load https://domain.com/theme
If I remove this two lines is working ok for http but not for https.
What can I do?
IMHO mixed mode, e.g. offering http as well as https never gives you what you expect: You expect security from https, but you always risk leaking session information, e.g. being vulnerable to session-hijacking attacks (ala Firesheep). My actual advice would be to go https only if you do https for security. Read on if that's not an option for you, but don't complain when you find information leaking (this is not dependent on Liferay, but for any web-based environment)
What is the exact problem that you have with the themes? (images/css through http?) Which version of Liferay are you using?
Before you specify more, you might want to configure your theme's "virtual path", this will rewrite all the URLs referring to your theme. It's typically used to serve static resources through a webserver or cdn, but it works with any kind of URL. Simply using a protocol-relative URL should work (I love this mostly unknown http feature):
Add this to your theme's liferay-look-and-feel.xml:
<look-and-feel>
<theme id="my" name="My Theme">
<virtual-path>//domain.com/myTheme</virtual-path>
</theme>
</look-and-feel>
note that the URL omits the protocol part, http: or https:, thus the browser will use the same protocol that the whole page is loaded with.
Edit: corrected the xml. Will investigate if there's a problem with protocol-relative URLs in themes.
Edit 2: Something is weird. It seems, virtual-path does not work like this, but I recall it did earlier. Do you add domain.com as cdn.host.http or cdn.host.https? (this would be concatenated)
On related stuff, please check if you're running Apache in front of your appserver. In this case you might forward some traffic for the portal (e.g. in the virtual host for http) but not forward the traffic in the https virtual host.
There is one use case I am unable to solve so far with the Apache Jakarta (Tomcat) Connector load balancing feature.
I have one IIS site which has one Apache Tomcat Connector attached to it. I need to "forward" the traffic to a different Tomcat depending on the URI that is requested. It is pretty simple to do when you only have apps with a specific context (like /app1, /app2, etc). My problem is that I have one app (in one Tomcat) that is at / (ROOT) and one other app (in another Tomcat) that is at /app1.
I have tried the following config in uriworkermap.properties:
/*=loadBalancer1
/app1/*=loadBalancer2
But this doesn't work, because "loadBalancer1" takes all the traffic. "loadBalancer2" is being ignored, which make sense, since /app1/* matches /* (regexp wise).
I also tried adding a exclusion as so:
/*=loadBalancer1
!/app1/*=loadBalancer1
/app1/*=loadBalancer2
But that doesn't work either, because "loadBalancer1" is still taking all the traffic, but just ignoring that "/app1/*" URI pattern. "loadBalancer2" is simply ignored again.
Any suggestion, keeping in mind that I cannot have 2 IIS sites, nor can I move the app that is at / (ROOT) to a different context path in Tomcat?
Thank you
Edit:
Instead of using just one Apache Tomcat Connector, I use 1 connector for each Tomcat on the same IIS site.
uriworkermap.properties #1: for Tomcat with app at / (ROOT)
/*=wlb
!/app1/*=wlb
uriworkermap.proerties #2: for Tomcat with app at /app1
/app1/*=wlb
Connector #1 will ignore traffic on URI "/app1/*", but connector #2 will catch it (and vice versa).
Now I can set different VM options and memory allocation to my apps!
I am open to comments or better solution..
Does it work when you reverse it as such ?
/app1/*=loadBalancer2
/*=loadBalancer1