title: Charles Proxy SSL certificate not accepted by browsers
body: <p>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.</p>
  <p>I managed to make this work with a simple rewrite rule and everything worked until today.</p>
  <p>The current problem is that the browser does not connect to the proxy (set up by Charles). The &quot;Failure&quot; field in the request says: &quot;No request was made. Possibly the SSL certificate was rejected.&quot;, and below, in the Notes field: &quot;You may need to configure your browser to trust the Charles CA SSL Certificate.&quot;.</p>
  <p>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:</p>
  <ol>
  <li>Uninstall and reinstall <a href="https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/" rel="noreferrer">the Charles certificate</a>.</li>
  <li>Try the same in the following browsers: Chrome Canary, Chrome stable, Safari and Firefox</li>
  <li>Use an HTTP Proxy instead of the —more advanced— SOCKS proxy.</li>
  </ol>
  <p>I also made sure that the Charles certificate is always trusted, no matter the default setting:</p>
  <p><a href="https://i.stack.imgur.com/fPE5m.png" rel="noreferrer"><img src="https://i.stack.imgur.com/fPE5m.png" alt="keychain access" /></a></p>
  
  <p>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:
  <img src="https://i.stack.imgur.com/tFx4X.png" alt="warning" /></p>
  <p>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.</p>
  <p>It is important to note that the actual host (let's say api.example.com) has a valid, purchased wildcard certificate for *.example.com.</p>
  <p>If anyone has a hint of how to fix this or what exactly is happening, I'd really appreciate her advice.</p>
  <p>Thank you.</p>
  <p>ps. If I tweak the direct request to have a proper Origin header (with sensible information amended/cleared):</p>
  <p>GET /xxx HTTP/1.1<br />
  Host: api.example.com<br />
  Connection: keep-alive<br />
  Cache-Control: max-age=0<br />
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,<em>/</em>;q=0.8<br />
  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<br />
  Accept-Encoding: gzip,deflate,sdch<br />
  Accept-Language: en-US,en;q=0.8,hu;q=0.6<br />
  Cookie: ...<br />
  Origin: <a href="https://acceptable.host.com" rel="noreferrer">https://acceptable.host.com</a></p>
  <p>I get the following response back:</p>
  <p>HTTP/1.1 400 Bad Request<br />
  Content-Length  46<br />
  Content-Type    application/json; charset=utf-8<br />
  Server  Microsoft-IIS/8.0<br />
  X-Powered-By    ASP.NET<br />
  Set-Cookie  ARRAffinity=secret-token;Path=/;Domain=api.example.com<br />
  Date    Wed, 21 May 2014 07:58:02 GMT</p>