7

I use Charles proxy (under OS X 10.9.3, Mavericks) to modify the Origin header so that an API (in development) I connect to accepts the incoming requests from the development environment.

I managed to make this work with a simple rewrite rule and everything worked until today.

The current problem is that the browser does not connect to the proxy (set up by Charles). The "Failure" field in the request says: "No request was made. Possibly the SSL certificate was rejected.", and below, in the Notes field: "You may need to configure your browser to trust the Charles CA SSL Certificate.".

I'd done this already and it worked perfectly. I have not changed anything in Charles's configuration since. The things I tried to get it working:

  1. Uninstall and reinstall the Charles certificate.
  2. Try the same in the following browsers: Chrome Canary, Chrome stable, Safari and Firefox
  3. Use an HTTP Proxy instead of the —more advanced— SOCKS proxy.

I also made sure that the Charles certificate is always trusted, no matter the default setting:

keychain access

Not sure if it's a clue to the solution but when I navigate to the api directly with Charles turned on, I see this: warning

The API is indeed hosted on the Windows Azure platform but I don't see why the Charles certificate (since Charles acts as a man-in-the-middle, showing its certificate to the browser) is made out to *.azurewebsites.com and not the actual host.

It is important to note that the actual host (let's say api.example.com) has a valid, purchased wildcard certificate for *.example.com.

If anyone has a hint of how to fix this or what exactly is happening, I'd really appreciate her advice.

Thank you.

ps. If I tweak the direct request to have a proper Origin header (with sensible information amended/cleared):

GET /xxx HTTP/1.1
Host: api.example.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hu;q=0.6
Cookie: ...
Origin: https://acceptable.host.com

I get the following response back:

HTTP/1.1 400 Bad Request
Content-Length 46
Content-Type application/json; charset=utf-8
Server Microsoft-IIS/8.0
X-Powered-By ASP.NET
Set-Cookie ARRAffinity=secret-token;Path=/;Domain=api.example.com
Date Wed, 21 May 2014 07:58:02 GMT

Community
  • 1
  • 1
Balint Erdi
  • 1,103
  • 2
  • 12
  • 20
  • What do you mean by 'when I navigate to the api directly with Charles turned on'? What's the difference with the first case, since in both cases Charles is on? – dirkgroten May 19 '14 at 15:18
  • Sorry, I was not clear. In the first case, I navigate to http://localhost:8000 and issue XHR requests to the API (https://api.example.com above) from there. In the second case, I navigate directly to the root of the API server, https://api.example.com . – Balint Erdi May 19 '14 at 15:22
  • So in the second case, if you 'Proceed anyway', what do you see in Charles? If Charles is indeed proxying the request, you should at least see the content returned by your server, the headers of which would give you some clue about why it's seeing *.azurewebsites.net instead of your own domain. – dirkgroten May 19 '14 at 15:26
  • And yes, I'm quite certain that if a direct request gives you this warning, you'd get an error with an XHR request. If you open your developer debugging console in Firefox, you should be able to see the error. – dirkgroten May 19 '14 at 15:27
  • I managed to get the direct request through and pasted the response headers as a p.s to my original question. – Balint Erdi May 19 '14 at 19:55
  • That is not the response, it's your request headers (GET, Connection, Accept are all request headers). There's another Tab in Charles that shows you the response headers. – dirkgroten May 20 '14 at 08:10
  • Sorry, it was too late, I guess :) I have now added the response headers, too. – Balint Erdi May 21 '14 at 08:15
  • the response says there's a bad request, i.e. the request URL or payload doesn't match what the server is expecting. Also it has a body (Content-Length 46) so maybe there's some JSON returned that gives an error reason? It looks to me like the issue is on the server, not on Charles. – dirkgroten May 21 '14 at 08:26
  • The 400 response is because the Origin header is not set so my request is rejected. The point is, I can make this work by explicity accepting the certificate ("Proceed anyway") but it seems like a hack and I have to do it every day or so. What I want to understand is why Charles presents a certificate from *.azurewebsites.com and not api.example.com? I thought Charles might have cached an incorrectly set up certificate a while back but the cert is now correct and it still presents the old one to browsers. – Balint Erdi May 22 '14 at 09:20
  • Furthermore even the warning cannot be bypassed now for HSTS sites, like google.com – cavalcade Mar 01 '15 at 02:03

1 Answers1

4

This is a super old question, but this is the answer that I found today for any folks that are still having issues with it.

https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/

You have to allow your machine to accept the Charles ssl certificate. (on a mac, this is done through the keychain).

user3456199
  • 41
  • 2