I just moved my Magento site from one server to another host/server. Everything works except for Cloudfront. The new server DOES have SSL, just like the last server did.
But now when I try to view anything from Cloudfront I get the error:
"CloudFront wasn't able to connect to the origin."
Is like the DNS cached at Amazon and taking them forever to update it? Is there something you need to do when moving a site to a new server to keep CloudFront working?
Making CloudFront work with SSL can be tricky, specifically when the hostname of the origin is different from the hostname of the CNAME.
For example, if your hostname is www.example.com, and the origin is www-example.us-west-2.elasticbeanstalk.com, the request from the cloudfront server will contain a Host header of the origin :
> GET /index.html HTTP/1.1
> Host: www-example.us-west.elasticbeanstalk.com
> User-Agent: CloudFront/2.3
> Accept: */*
The origin host needs to be able to handle authenticated SSL requests for www-example.us-west.elasticbeanstalk.com, but usually you set it up in such way that it can handle SSL requests for the original hostname, www.example.com. In which case you have two options :
Whitelist the Host header. This will cause CloudFront to send the same Host header ( Host: www.example.com ) to the origin, which should be able to handle it correctly :
Another option is to set your origin to be the same hostname with a different subdomain, for example set the origin as origin.example.com and set a CNAME between origin.example.com and www-example.us-west.elasticbeanstalk.com
Related
I want to access data on a remote server from a local computer via an http request. I am getting this error:
Cross-Origin Request Blocked ... Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘[ip address].
The local machine is an angular project running on localhost:4200, the remote data is accessed via a php script located on the web (eg. https://example.com/php )
My question is: what are the appropriate header settings on my request from localhost:4200 (the client/requesting computer) and in the mod_headers section of the .htaccess file on my server (apache).
On the client side I have tried the following, where 111.111.111.111 is the IP address of the client and example.com is the domain name of the server.
headers.append('Access-Control-Allow-Origin', 111.111.111.111);
headers.append('Access-Control-Allow-Origin', http://111.111.111.111);
headers.append('Access-Control-Allow-Origin', '*')
headers.append('Access-Control-Allow-Origin', 'example.com')
headers.append('Access-Control-Allow-Origin', 'http://example.com')
On the server side .htaccess file (located in the folder of php script I am trying to launch) I have tried the following, where the 111.111.111.111 is the ip address of the machine making the request.
Header always set Access-Control-Allow-Origin "111.111.111.111"
Header always set Access-Control-Allow-Origin "http://111.111.111.111"
Header always set Access-Control-Allow-Origin "*"
Recap:
Does Access-Control-Allow-Origin need to be set on the request header, if so to what? The client's ip address? The server's ip address?
Do any other headers need to be set on the request, for example Access-Control-Request-Method?
Can an ip address be used in the server's .htaccess file or must it be a domain name? Does it need to be pre-pended with http:// or https://?
A client of mine is trying to use an IIS Application Request Routing rule to reverse proxy the contents of another site (controlled by the same client). So far, no issues.
But, from the IIS server the other site is only available through a standard HTTP proxy. It looks like ARR totally ignores the System and .NET Proxy settings.
We tried setting the default proxy in the web.config, that is ignored.
We tried setting the system proxy through netsh winhttp set proxy.
We changed the settings in the Internet Explorer connection settings.
All to no avail.
I can't find any documentation on whether ARR supports reverse proxy rules through another proxy. I can imagine this is not supported.
An HTTP request over an HTTP proxy is actually making the same request to the proxy using the absolute url instead of relative in after the method name.
GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
would be
GET http://example.com/ HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Of course the request needs to be made to the proxy server.
You could try achieving this changing rewrite rule. I can't provide an example since I don't have access to a Windows server but you can try to get some guidance here.
I have setup cloudfront, elb and my ec2 web server for default behavior (no caching), everything is working fine. There is only 1 origin (the elb) and the origin path is empty.
Now I want to cache static stuff with cloudfront from the web server (wildfly) like js/css, they're all served in /my-context/assets folder
So i add a new behavior with path pattern '/my-context/assets/*' and default cache settings using the same origin.
This is not working, my request login page return the page html itself, but all css/js are failed. Request to /my-context/assets/a/b/some.css return 502 with "CloudFront wasn't able to connect to the origin."
I also tried to setup a new origin (with the same elb) with path "/my-context/assets" for the new behavior, it also fail.
Can I have instruction on how to make this work? or is this actually not do-able?
Thank you!
The solution is to configure the cache behavior to forward (whitelist) the Host: header to the origin, from the incoming request.
This is not to imply that it's the "correct" configuration in every case, but many times it is desirable, or even required.
When CloudFront makes a back-end https connection to your origin server, the certificate offered by the server has to not only be valid (not expired, not self-signed, issued by a trusted CA, and with an intact intermediate chain) but also has to be valid for the request CloudFront will be sending.
For CloudFront to use HTTPS when communicating with your origin, one of the domain names in the certificate must match one or both of the following values:
• The value that you specified for Origin Domain Name for the applicable origin in your distribution.
• If you configured CloudFront to forward the Host header to your origin, the value of the Host header.
The SSL/TLS certificate on your origin includes a domain name in the Common Name field and possibly several more in the Subject Alternative Names field. (CloudFront supports wildcard characters in certificate domain names.) If your certificate doesn't contain any domain names that match either Origin Domain Name or the domain name in the Host header, CloudFront returns an HTTP status code 502 (Bad Gateway) to the viewer.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html#SecureConnectionsHowToRequireCustomProcedure
In your case, you originally were running requests through CloudFront with caching disabled, which is typically done by configuring CloudFront to forward all request headers to the origin, as this automatically disables caching of responses.
Later, when you attempted configure a second cache behavior so that objects matching certain path patterns could be cached, you naturally did not forward all headers to the origin -- but in this case, forwarding the Host: header (which CloudFront refers to as "whitelisting" the header for forwarding) was necessary, because CloudFront appeared to have needed that information in order to validate the certificate that the origin server was presenting.
If you don't forward the Host: header, the the certificate must match the Origin Domain Name, as noted above, and in your case, this us apparently not the case. If the Host: header is not whitelisted for forwarding, then CloudFront still sends a host header in the back-end request, but this header is set to the same value as Origin Domain Name, hence the reason the certificate must match that value.
If matching one way or the other were not required (along with all the other conditions CloudFront imposes on HTTPS connections to the origin), this would prevent CloudFront from determining with reasonable certainty that the back end connection was being handled by the intended server, and that the origin server is genuinely the server it claims to be, which is one of two protections provided by TLS/SSL (the other protection, of course, is the actual encryption of traffic).
I've setup an alternate domain name for our Cloudfront distribution so we can serve from oursite.com. We'd like to disable ourdistid.cloudfront.net so our site is only accessible from one hostname. Is this possible?
Yes, you can do this, though perhaps not in the place where you might expect to.
By default, CloudFront sets the Host: header in the request sent to the origin server to have the value of the origin server hostname.
However, you can configure CloudFront to forward the original request's host header to the origin server, instead. It doesn't change how the request is routed, only the header that gets forwarded.
After that, it is a simple matter to configure your web server to return the response you want, when the request's Host: header matches the *.cloudfront.net host, which can include a generic error page with whatever code you seem most appropriate, such as 503 Service Unavailable, 404 Not Found, 403 Forbidden, or 410 Gone. You could even use 301 Moved Permanently. Whatever makes the most sense to you.
You can't literally disable the assigned endpoint, but you can prevent it from returning any of your content.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html
On my windows 2003 server I have two websites: 2send.co.il & oferavnir.co.il
For 2send.co.il I installed SSL.
When I adding Https to oferavnir.co.il (the site without the SSL) the other site content is displayed -
(https://oferavnir.co.il displays the content from 2send.co.il)
Host headers for both site seems to be ok.
What could it be?
By default, the SSL certificate is probably bound to all IP addresses on your server. If you have individual IPs for each site, you can update the binding to only listen on the IP for 2send.co.il. If you are using host headers and a single IP, the 2send.co.il site will respond for all https requests. You could use a product like ISAPI Rewrite to check the URL used for an HTTPS request and ensure that it matches 2send.co.il or else route it to the appropriate http site for the URL
http://forums.iis.net/t/1195794.aspx/1?HTTPS+displays+other+site+contnet