blob: 16dd9d8fdc30517a319a79f7fd3512a6537868fe (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
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>
<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>
</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 validiy 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")!@)
|
