I would like to have Charles decrypt HTTPS traffic when browsing in Chrome on MacOS.
But when I visit a website (for example, https://www.facebook.com), there are errors about net::ERR_SPDY_COMPRESSION_ERROR on multiple resources.
How can I fix this?
Steps I've followed so far:
Open Keychain Access, search for charles and delete every item mentioning charles
Open Charles Proxy, chose Help > SSL Proxying > Save Charles Root Certificate... and save charles-ssl-proxying-certificate.pem
Open Keychain Access again, click File > Import Items..., choose charles-ssl-proxying-certificate.pem, click Open.
Double click on the new certificate, click Trust, then for When using this certificate: select Always Trust
Close the window, and enter my password in the Certificate Trust Settings popup, and click Update Settings
Close Keychain access.
In Charles Proxy, select Proxy > Proxy Settings.... Check Enable SSL Proxying and enter *:* in the Location. Click Ok.
Restart Charles and Chrome.
Enable MacOS Proxy in Charles.
Visit https://www.facebook.com in Chrome incognito window.
I see multiple net::ERR_SPDY_COMPRESSION_ERROR errors in the Chrome Inspector Console.
I also tried the same steps, except using Install Charles Root Certificate from the Charles Proxy Help menu, but it results in the same problem.
Charles 4.0.2
Network: WPA2 WiFi
VPN: no
OS: MacOS 10.12.5
Chrome: 58.0.3029.110
Upgrading Charles to version 4.2.7 solved the problem for me (version 4.0.2 had the problem). I think the fix is included in 4.2.5 improvements: SSL Proxying support extended to Port Forwarding and non-HTTP SOCKS traffic.
Related
I am not able to load the https sites on google chrome. I have successfully installed the Burps certificate but still am not able to resolve the problem. However the sitemap is getting populated by the https site i am navagating.
It came with error:
This site can’t provide a secure
site sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR
This issue was because of the TLS certificate in the older version of the Burp Suite. In the newer version, this issue seems to be fixed.
In which browser you are trying to load sites through burp proxy?? Bcoz in some browser certificate needs root permission. You can install certificate for user, root, server , etc. So check again if you are giving all the permission to certificate or not. If you are using firefox then install certificate in "Authorities" . Also try to close browser , clear cookies , set same proxy & port in burpsuite and browser.
I have a ClearOs Linux server which, amongst other things, runs a CUPS print server. Installing CUPS makes an admin interface available via https protocol.
Every time I connect to this admin server, Chrome (and IE) warns me the certificate is invalid, and I have to click twice more to go through to the site.
I would like to tell Chrome to trust this certificate. I have Googled how to do this, and tried 3 or 4 different recipes - none of them seem to have worked (the certificate is still not trusted). I have tried the following:
Connect to the site via IE running as Administrator, click on the invalid certificate flash next to the url, view certificate, install certificate, choose Trusted Root Certificate store, and install it. I also tried the Personal store and the Trusted publishers store.
Connect to the site via Chrome, click on the certificate and export it, do Settings/Advanced/Manage certificates, and import it into the store (again, I tried Trusted Root and Personal stores).
I also tried some other instructions which said to start by running "MMC" from the Windows Start button - but typing MMC only offers me Hyper-V manager and Sql Server 2017 Configuration Manager - not the management console expected.
I have read Getting Chrome to accept self-signed localhost certificate here, and tried everything there that applies to Windows 10, but nothing works.
Enter “chrome://flags/#allow-insecure-localhost” in your chrome browser and “Allow invalid certificates for resources loaded from localhost.” to bypass the security warning about your self signed certificate.
Chrome 58+ drops support for CN in SSL certs, which means (at least on my machine) that browsing sites hosted in IIS Express throw constant security warnings.
How do I change my IIS Express SSL certificate for one that will work with Chrom 58+?
This is how I fixed this. There may be an easier way (I'm sure there is!)
Step 1 - Open Windows PowerShell (in admin mode) and generate a certificate like this:
New-SelfSignedCertificate -DnsName "localhost", "localhost" -CertStoreLocation "cert:\LocalMachine\My"
Keep the thumbprint safe.
Step 2 - Open a command prompt (in admin mode) and run these commands.
The first will delete the current IIS Express certificate for ports 44300-44399.
for /L %i in (44300,1,44399) do netsh http delete sslcert ipport=0.0.0.0:%i
The next will add your new certificate to those ports. Change the thumbprint obviously.
for /L %i in (44300,1,44399) do netsh http add sslcert ipport=0.0.0.0:%i certhash=33459ADA4D5329673604F43A073B7F43084818A7 appid={214124cd-d05b-4309-9af9-9caa44b2b74a}
The appid is for IIS Express 10 I believe. You may want to check your IIS Express appid is the same as mine first. To do that do this:
netsh http show sslcert
Step 3 - Restart IIS Express and Chrome, then run up one of your sites in Chrome.
It'll give you the security warning again. Proceed to the page then go into settings > advanced settings, HTTPS/SSL Manage certificates.
In here, export the certificate from Personal and import the certificate to Trusted Root Certificate Authorities (I did it as .p7b) then restart Chrome.
Try the site again - you should be secure now.
You can do all this outside of Chrome in certmgr as well.
Edit: Alternate steps for Step 3 above using certmgr:
Hit win key and type "certmgr" to open the Windows cert manager.
Expand Certificates - Local Computer > Personal > Certificates and find the cert you just created (it should be issued to localhost and have an expiration one year from the current date).
Select the cert and ctrl-c to copy.
Expand Certificates - Local Computer > Trusted Root Certification Authorities > Certificates and ctrl-v to paste.
The answer Chris gave solves the issue, thanks! Because my whole team had this issue, I created a little Powershell script to run the steps in Chris' answer.
https://gist.github.com/camieleggermont/5b2971a96e80a658863106b21c479988
Running this in elevated mode did the trick for me.
I am just using this setting until it is fixed in Visual Studio:
chrome://flags/#allow-insecure-localhost
It just prevents having to allow the security exception each time but it will still show the SSL as invalid (red) in your browser bar.
The solution provided by Chris does do the trick (thanks!), but ultimately this should be fixed by the visual studio team. You can vote here in order to bring this issue to their attention:
https://developercommunity.visualstudio.com/content/problem/48596/visual-studio-2017-151-264037-crashing-during-code.html
A more visual way to fix it is to use Jexus Manager to,
Generate a new certificate.
Let Windows (and Chrome) trust it.
Bind it to the site.
I documented the exact steps in a blog post.
I want to use fiddler to monitor api calls made by my browser when it visits some pages.
The technology - Fiddler 4.6x, Chrome 56, Firefox 51, Windows 7 64 bit.
The problem - Fiddler does not work with chrome. When I open any page on chrome, I get the error "Your connection is not private: Attackers might be trying to steal your information from website (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID". FYI, I easily fixed a similar issue with firefox.
Solutions I tried that failed -
Four hours of google and stack overflow did not give me any solutions.
Convert the fiddler cert to pk 7 ??? format.
Import fiddler cert into chrome. Also, grant the cert all kinds of advanced permissions.
Install the fiddler cert with admin rights on windows, by "running" it.
Run chrome and ignore cert errors.
Regenerating the fiddler cert and restarting fiddler and browsers as given in the official fiddler book.
In 2,3 the cert never appeared in trusted cert store, but appeared in personal and immediate cert store. In 1, nothing even happened. Please tell me how I can make this work. Any links to the basics of all this would help.
I was facing similar issue with Fiddler v4.6 and followed these steps:
Fiddler 4.6.1.5+
Click Tools > Fiddler Options.
Click the HTTPS tab.
Ensure that the text says Certificates generated by CertEnroll engine.
Click Actions > Reset Certificates. This may take a minute.
Accept all prompts
Fiddler 4.6.1.4 and earlier
Click Tools > Fiddler Options.
Click the HTTPS tab
Uncheck the Decrypt HTTPS traffic checkbox
Click the Remove Interception Certificates button. This may take a minute.
Accept all of the prompts that appear (e.g. Do you want to delete these certificates, etc)
(Optional) Click the Fiddler.DefaultCertificateProvider link and verify that the dropdown is set to CertEnroll
Exit and restart Fiddler
Click Tools > Fiddler Options.
Click the HTTPS tab
Re-check the Decrypt HTTPS traffic checkbox
Accept all of the prompts that appear (e.g. Do you want to trust this root certificate)
Reference:
https://textslashplain.com/2015/10/30/reset-fiddlers-https-certificates/
I used these two stack overflow posts -
https://superuser.com/questions/145394/windows-7-will-not-install-a-root-certificate
https://superuser.com/questions/647036/view-install-certificates-for-local-machine-store-on-windows-7
I don't know what is happening. One of these posts worked and I got the fiddler cert into the trusted store. But, fiddler still cannot decrypt many websites https traffic, especially that of google.
After I reinstalled fiddler and did what Abir suggested Fiddler still didn't capture any traffic.
In my case it stopped working because I installed a chrome extension named Tunnel Bear, uninstalling the extension solved it for me.
Firefox has its own certificate store so I assume you just installed the DO_NOT_TRUST... Fiddler root cert there and everything worked. Pretty much you should do the same with Windows certificate store in order for Chrome to work. So make sure you remove all the fiddler certificates you previously generated and regenerate.
if fiddler do not capture chrome traffic, one solution is checking extensions. in my case i use zenmate vpn. when i disable this extension, fiddler capture all traffic in chrome
I've got a web site that uses SSL Client certificate authorization.
All client certificates are generated using OpenSSL and are self-signed. Everything worked with all web-browsers, but the recommended one was Google Chrome, because it uses same SSL warehouse as IE, so certificate installation was pretty easy (click-click-password-done!).
After last update of Google "Chrome 29.0.1547.57 m", noone can access my web-server, even me.
Google chrome error only! IE and FF working fine.
Error is: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.
Same in server error log.
Do you have any suggestions?
The problem is that most part of clients are non familiar with PC's and they got very frightened about that situation. So phone support guys are under the wave of calls.
We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP
negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384)
hash function.
We found that Chrome fails when it receives "client certificate request" following SERVER HELLO.
SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic
packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.
Invoking Chrome with "--enable-logging --log-level=0" outputs the following message:
ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816
This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.
I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.
Anyone else seeing this?
EDIT:
I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?
I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).
EDIT2:
Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.
I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.
The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.
To do the reset:
In Keychain Access app right-click each private key that fails and select "Get Info".
Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.
It is combination of Win XP and Google Chrome 29.0.1547.57 m
On Win 7/8 this problem doesn't occur.
You could install older working version 28.0.1500.95
http://www.filehippo.com/download_google_chrome/15657/
But settings for disabling updating are not so easy.
http://dev.chromium.org/administrators/turning-off-auto-updates
The problem is caused by Chrome running TLSv1.2 on Windows XP.
This can be disabled on the server side but also on the client side.
To run Chrome with a lower version of TLS, start it with the command-line option --ssl-version-max=tls1.1
I had this problem Connecting Chrome with WebSockets to apache throw proxy_wstunnel_module.
My solution was configuring httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets does not like the parameter SSLVerifyClient optional
I hope this helps.