The first time __mitmproxy__ or __mitmdump__ is started, the following set of
certificate files for a dummy Certificate Authority are created in the config
directory (~/.mitmproxy by default): 

<table class="table">
    <tr>
        <td>mitmproxy-ca.pem</td>
        <td>The private key and certificate in PEM format.</td>
    </tr>
    <tr>
        <td>mitmproxy-ca-cert.pem</td>
        <td>The certificate in PEM format. Use this to distribute to most
        non-Windows platforms.</td>
    </tr>
    <tr>
        <td>mitmproxy-ca-cert.p12</td>
        <td>The certificate in PKCS12 format. For use on Windows.</td>
    </tr>
    <tr>
        <td>mitmproxy-ca-cert.cer</td>
        <td>Same file as .pem, but with an extension expected by some Android
        devices.</td>
    </tr>
</table>
    
This CA is used for on-the-fly generation of dummy certificates for SSL
interception. Since your browser won't trust the __mitmproxy__ CA out of the
box (and rightly so), you will see an SSL cert warning every time you visit a
new SSL domain through __mitmproxy__. When you're testing a single site through
a browser, just accepting the bogus SSL cert manually is not too much trouble,
but there are a number of cases where you will want to configure your testing
system or browser to trust the __mitmproxy__ CA as a signing root authority:

- If you are testing non-browser software that checks SSL cert validity using
the system certificate store.
- You are testing an app that makes non-interactive (JSONP, script src, etc.)
requests to SSL resources. Another workaround in this case is to manually visit
the page through the browser, and add a certificate exception.
- You just don't want to deal with the hassle of continuously adding cert
exceptions.


Installing the mitmproxy CA
---------------------------

* [Firefox](@!urlTo("certinstall/firefox.html")!@)
* [OSX](@!urlTo("certinstall/osx.html")!@)
* [Windows 7](@!urlTo("certinstall/windows7.html")!@)
* [iPhone/iPad](@!urlTo("certinstall/ios.html")!@)