I've a problem regarding Stripe Webhooks (and some other tools). Somehow we receive HTTP 525 errors since a few days. So there seems to be a SSL handshake error. The strange thing is, that only Stripe and a few crawl bots are affected. The website works as expected when I visit it with various browsers.
Here is some analytics data from Cloudflare:
All of them seem to have an empty X-Requested-With header.
Any idea what I can do?
We use Cloudflare and Cloudflare Loadbalancers. All traffic is proxied by Cloudflare. We have 2 origin servers. I've already created and installed new certificates, added/changed ciphers, added/updated different TLS versions, changed SSL mode within Cloudflare from Off to Full (strict) and all options between.
Related
I have a react-native application which I'm hooking up to an existing API which already has two clients (webapp, chrome extension). For some reason I just get the generic [TypeError: Network request failed] with nothing more.
The requests that are failing are just basic get requests such as
fetch('https://api.mydomain.com/pages/') or axios.get('https://api.mydomain.com/pages/') and they work fine from the webapp and chrome extension that are using this API as well - the requests only fail from the react-native application.
Everything I'm finding on google for this is in regards to localhost or SSL Certificate problems, although these are not my issues because I'm trying to pull from a deployed server and also that server has SSL correctly enabled and I'm using the https endpoint.
Some more notes:
when I do go against localhost (using the IP Address, not localhost address) I get this same error.
I'm getting this error on Android and I haven't touched nor am concerned yet with iOS
I get this same error with fetch and axios
The request goes through OK with this endpoint https://jsonplaceholder.typicode.com/posts/1 and I get back a response
This last note is the most interesting because I believe that means there is some issue with my server, however my server is not receiving any request... I have opened up CORS for testing purposes but have the same issue, although if that were the issue the server would have received the request and responded with 403.
This has to do with Android not trusting my SSL certificate. Apparently Android has some additional trust requirements on top of what web browsers require.
I found this through error.request._response via the axios catch block which showed me the error java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
After figuring that out, the root cause ended up being my SSL Certificate uploaded to AWS didn't have the correct intermediate cert which was fine in chrome, but not in android.
The problem:
I have 2 websites that have the same IP address (a domain and a subdomain), and I have an SSL certificate for each of them. The domain is a word-press site while the sub domain is a ruby on rails application. the subdomain has the certificate installed and works with no problems, but when I try to add the second certificate for the main domain, it works, but it prevents access to the subdomain.
In the web browser inspection page it shows this error :
“XMLHttpRequest cannot load https://giladparking.com/wp-content/plugins/wp-slimstat/wp-slimstat-js.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://monthly.giladparking.com' is therefore not allowed access.”
What I have tried:
I have followed this tutorial to allow for SNI support and it seems to work except for the previously mentioned issue.
I have taken a look at this post as well which explains that you can't make XMLHTTPRequests across domains. but this issue only arises when both certificates are in effect.
“XMLHttpRequest cannot load https://giladparking.com/wp-content/plugins/wp-slimstat/wp-slimstat-js.php....
The certificate for this sites is valid for monthly.giladparking.com and www.monthly.giladparking.com but not for giladparking.com. That's why any access to this site will fail with a certificate error. This problem is not restricted to XMLHTTPRequests.
I am trying to have links in my emails from my application register as SSL/HTTPS secure links. This helps deliverability and other things email clients may do treating links as http vs https.
Our application is using SendGrid to send emails, which also supports click tracking on our links for us. In order to do this SendGrid, and most other email sender services replace the original link we put in, which was an https://blahblah.com link with their own link, http://clicktrack.sendgrid.net or something that is not https, but rather http.
SendGrid supports "white labeling" the click tracking link with something like
http://subdomain.blahblah.com and also https version if we set it up properly. SendGrids requirements for https/ssl link are shown here
https://sendgrid.com/docs/Classroom/Build/Add_Content/content_delivery_networks.html
Basically they are asking us to setup a CDN or other server that will host our SSL certificates, terminate the SSL, and then forward the request on to their servers. Once that is in place they can "turn on" ssl on their end for our email links.
I tried setting this up in AWS CloudFront with the origin as sendgrid.net and the distribution having our SSL certificate and a route 53 CNAME pointing to our distribution. So the subdomain.blahblah.com points to distribution CDN, CDN points to sendgrid, and all should work.
Testing this though it does NOT work. If I go to the http version of subdomain it does work, CDN forwards properly. AWS support has suggested it was an issue related to host headers and the CDN not being able to validate the origin when I had a 2nd CNAME for the origin on my subdomain2.blahblah.com. That led me to remove 2nd cname and direclty put sendgrid as origin, but that hasn't worked and they haven't provided a solution yet. I get error like this..
ERROR
The request could not be satisfied.
CloudFront wasn't able to connect to the origin.
Generated by cloudfront (CloudFront)
Request ID: pl1bS3OObC6mUd2vyyhM6bNFt3xyLsfzVIqNmiPkEO7mQgJyQCn_pA==
Any ideas welcome or a different way to do this?
The issue was in behaviors I was forwarding all headers. Should NOT forward "Host" header in this situation or the origin ssl call will break as it wont match expected. AWS support did finally figure this out and recommend to me :)
after upgrading to Safari 9 I'm getting this error in the browser:
[Warning] [blocked] The page at https://localhost:8443/login was not allowed to run insecure content from http://localhost:8080/assets/static/script.js.
Anyone knows how to enable the running of insecure content on the new Safari?
According to the Apple support forums Safari does not allow you to disable the block on mixed content.
Though this is frustrating for usability in legitimate cases like yours, it seems to be part of their effort to force secure content serving / content serving best practices.
As a solution for you you can either upgrade the HTTP connection to HTTPS (which it seems you have done) or proxy your content through an HTTPS connection with an HTTPS-enabled service (or, in your case, port).
You can fix the HTTPS problem by using HTTPS locally with a self signed SSL certificate. Heroku has a great how-to article about generating one.
After setting up SSL on all of your development servers, you will still get an error loading the resource in Safari since an untrusted certificate is being used(self signed SSL certificates are not trusted by browsers by default because they cannot be verified with a trusted authority). To fix this, you can load the problematic URL in a new tab in Safari and the browser will prompt you to allow access. If you click "Show Certificate" in the prompt, there will be a checkbox in the certificate details view to "Always allow content from localhost". Checking this before allowing access will store the setting in Safari for the future. After allowing access just reload the page originally exhibiting a problem and you should be good to go.
This is a valid use case as a developer but please make sure you fully understand the security implications and risks you are adding to your system by making this change!
If like me you have
frontend on port1
backend on port2b
want to load script http://localhost:port1/app.js from http://localhost:port2/backendPage
I have found an easy workaround: simply redirect with http response all http://localhost:port2/localFrontend/*path to http://localhost:port1/*path from your backend server configuration.
Then you could load your script directly from http://localhost:port2/localFrontend/app.js instead of direct frontend url. (or you could configure a base url for all your resources)
This way, Safari will be able to load content from another domain/port without needing any https setup.
For me disabling the Website tracking i.e. uncheck the Prevent cross-site tracking worked.
I am trying to optimize my site for all HTTPS. I know that Twitter is all HTTPS and I noticed that they don't redirect HTTP to HTTPS, but instead just initiate an HTTPS connection.
Here is a screenshot of Google Chrome's Network Activity, notice there is no redirect (301/302), the HTTP request (first line) just hangs as pending and the second line is the HTTPS page. Note, I have cleared all my browser cache so HTTP Strict Transport Security (HSTS) shouldn't matter.
Here is another screenshot of the request/response for the HTTPS page. Notice, that it seems Twitter inserts some fields into the REQUEST, such as :scheme
How do they do this? I would assume its faster so that if a user types twitter.com into their browser, instead of a redirect (think extra network round trip), Twitter seems to seamlessly move to SSL (HTTPS).
A follow on question would be, does this work in all browsers?
They have been added to a list of preloaded HSTS sites in Chrome and Mozilla Firefox.