Similar to this question:
Chrome Doesn't Trust Fiddler Root Certificate
But the upvoted answer (https://stackoverflow.com/a/33818661/1250301) doesn't seem to be working for me in fiddler v 5.0.
If I load a site with https in chrome I get NET::ERR_CERT_AUTHORITY_INVALID message. If I "reset all certificates" under the HTTPS tab of the options dialog (as per the suggestion in the answer) then I no longer get the certificate errors in Chrome, but Fiddler will only intercept the "Tunnel to" requests and nothing else. If I close fiddler and restart it, then my certificate is no good again for some reason!
Related
All request comes on HTTPs and internally managed on HTTP. Everything works fine until it hits re-direct return "redirect:/link/somePage.htm";
The moment redirect is called, Chrome browser complains about insecure page and the message displayed is The information you’re about to submit is not secure. The same works fine on Firefox.
Of course redirect causes link to change from HTTPs to HTTP on Chrome. Where as Firefox has no issue.
Has anyone encountered this recently on above mentioned browsers or something underline has changed, which would mean deeper investigation.
Firefox - 81.0.2 & 83.0, Chrome - 87.0.4280.88
We searched for a solution all day long.
We found that we need to add the following headers:
For Appache server: RequestHeader set X-Forwarded-Proto https
For NGINX server: proxy_set_header X-Forwarded-Proto $scheme;
Another possible solution on NGINX with reverse proxy is to use the command :
proxy_redirect http:// https://;
Source : https://community.bitnami.com/t/ssl-https-connection-implemented-but-getting-error-while-accessing-some-pages/89877/4
We had this problem, reported to me on Monday (12/14/2020). It was reproduceable on Tuesday (12/15/2020). Today, Wednesday (12/16/2020) we do not get the warning from Chrome. No changes have been made to the site. However, accessing the site with lighthouse, does report the problem. Did something happen to change the detection or reporting?
I am evaluating W3C pay Google examples by enabling the Chrome Extension from Google's example here: https://bobpay.xyz/ (Clicking "Install web payment app" on the bottom). This installs the W3C Pay Chrome extension.
I then use their demo here:
https://paymentrequest.show/demo/
I am able to submit a payment using the "Bobpay" extension, see below:
... however when it comes time to redirect to the Bob pay "Account Selector" web application (the front end of the Payment Handler), I get the following error in Chrome's Developer tools:
"Aborting payment handler window "https://bobpay.xyz/pay" because of navigation to an insecure url "chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh/data/shared/tpc-check.html"
It's complaining that the redirection to the chrome-extension URL scheme is insecure.
I already took both Certs from bobpay.xyz and paymentrequest.show sites, and installed them to my System keychain. Then I trusted both SSL certs. This didn't help.
BTW, this works on Windows, but not on MacOS (Chrome on both).
Also: submitting a sample credit card payment outside of the Bobpay extension works fine (by using a locally stored Credit card option, and not the Bobpay extension) - returns tokenized card to be forwarded to payment processor.
This demo code also does not work on any other browsers, such as Firefox or Safari (unsupported on both).
In the Security panel of Chrome Developer tools, we can also see that the Chrome Extension for Bobpay is marked as "Unsecure":
I also installed the whole thing on Localhost, created a self signed SSL cert, added it to keychain, trusted it, and ran an https-server with that cert, but I get the same issue on https://localhost:8080/bobpay as well.
After verifying that the demo worked on another MacOS machine, I figured I introduced an issue trying to clone bobpay and deploy it on localhost under another name. The two payment handlers were somehow trampling over each other, when redirecting to the Frontend Handler page.
I ended up removing all Chrome files in ~/Library/Application Support/Google/Chrome, clearing all Chrome settings (reset to default), and re-installing Chrome. This cleaned out all extensions, cached data, and service workers under Dev Console --> Application. I am now able to proceed without errors.
After some experiments with PWA I've encountered a strange issue with Google Chrome only. Every other browser works just fine.
When I load http://localhost the response is: "This site can’t be reached"
The error status is: "ERR_FAILED" (404)
Note:
"ping localhost" returns 127.0.0.1 (as it should be).
wget -qO - 'http://localhost' loads the correct content in terminal.
every other browser loads the correct content.
the setting in /etc/hosts leads to 127.0.0.1
if I access the content via IP (127.0.0.1) it loads just fine.
I have cleared the browsing cache
the PWA cache seems to be clean.
The offline box in the network tab is not checked.
If anyone has any ideas on what could cause the issue please share.
The only clue I have is that in the sources tab of the code inspector
there's the content of sw.js (my service worker) but there's nothing to do with it.
I came out that the issue was caused by a cookie called ServiceWorker.
After deleting it everything works fine.
I am trying to follow the following link
http://blog.nanthrax.net/2012/12/how-to-enable-https-certificate-client-auth-with-karaf/
I am able to access the Webconsole with SSL in IE
But it is not working in Chrome I am getting and Certificate error.
why it is not working in chrome ? I am getting ssl_server_cert_untrusted_issuer
Your certificate is not signed by a trusted issuer. See here for the difference.
signed vs self signed certificates
Also, if you watch your screenshot of the IE closely, you can see that there is also a certificate error. Chrome is per default more restrictive than IE.
If you want to view the page in chrome, you can do this by adjusting chromes settings or install your certificate.
I am currently doing some debugging on my website which involves calling the facebook API.
I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
I have a echo server which will print out all the raw http request header on port 80 on my laptop.
Now comes my problem. When I access facebook.com, I realize chrome will automatically forward http:// to https:// for facebook.com
I googled and found the way of deleting this HSTS issue. I visit chrome://net-internals#hsts to see something like this:
HSTS chrome image
After entering "facebook.com" under "Delete domain", I can still query "facebook.com" in the input box below.
I tried clearing all user data on chrome, closing and reopening chrome and even using incognito mode.
Why is chrome still redirecting all request to facebook.com to https?
How can I disable this if chrome://net-internals#hsts is not
reliable?
The text next to the Delete domain box on chrome://net-internals/#hsts clearly states that preloaded entries cannot be deleted. This feature request was closed as WontFix in the Chrome bug tracker.
facebook.com and quite a few of its subdomains are included in Chrome's preload list.
You could use another domain name for your tests.
Just make api-calls to facebook-api-test.com, map that domain to localhost and proxy the calls.