旧方法或有过时。对有效旧方法未阐明的细节进行发掘和新方法的探索，重新总结两种下载BurpSuite的CA证书方法，并分别导入到Chrome和Firefox。版本为2022。

下载

重点在这里：

以上选择路径（select file），选择以后直接摁保存没有反应，因为要在File Name上输入cacert.der（der后缀别忘了），选择保存：

成功导出证书，在你所保存的路径下就能找到。

小结：以上方法是从burpsuite本身所导出的证书，具有一般性，另一个方法是通过Firefox插件：

添加成功以后，固定到工具栏：点击选项：

点击添加，红色框为必填项，然后save保存。

比如，bp1就是这么来的：

我们直接在搜索框搜索burp，结果是：

点击右上角的插件再点击bp1：

看到图标变化即表示相应的proxy已开启：

刷新一下页面：

点击右上角CA Certificate：

选择你想要的路径并保存就完成下载了！

导入证书

打开设置（不用我教了吧），并输入证书，选择查看证书：

找到刚刚证书的下载路径和证书文件并导入就完成啦！

针对于火狐的证书下载和导入已经告一段落，如果没有深入研究下去的需求可以出门左转了。

Chrome的导入

设置->证书->管理证书：

点击可信证书的导入：

导入成功就会跟上面这张图类似。

答疑

但如果你也跟我一样用了另一种代理来使用chrome（dddd）：打开自动检测->修改手动设置代理的端口。

重新打开那个另一个代理：

再重新打开系统代理就会发现：

所以结论是什么？代理的不相容性（扯）！简单地说，就是如果你的浏览器本身需要依赖一种代理才能上网，他就容不下第二个代理，比如bp；其他浏览器比如bing的代理插件，我没有试，但比如火狐，比如bp1端口号为8080，bp监听的端口号也为8080，也是可以抓包的，却也只限于正常上网（代理不相容原理）。但这只是因为火狐能够灵活调整。如果调整到9674：

而bing是能够跟随着那另一个代理上网的。出于严谨，再强调一遍，bing的代理插件我没有去试，因为不认为有意料以外的结果。因为从原理上说：当两者同时使用时，会导致网络路由混乱。例如，另一个代理可能会将原本应该发送到 Burp Suite 代理的请求直接发送到 另一个代理 的服务器，使得 Burp Suite 无法正常拦截和处理这些请求。

不相容的直接证据是：

关于系统端口的直接修改，我也替大家试过了：

会导致所有浏览器都用不了。

想必问题的定位和基本矛盾已经很清楚了，至于具体怎么优化代理设置，就是另一个话题了。