首先明确一个概念：非对称加密算法
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
HTTPS协议中，前面的握手过程，服务器会将公钥发给客户端，客户端验证后生成一个密钥用公钥加密后发送给服务器，成功后建立通信。
通信过程客户端将请求数据用得到的公钥加密后，发给服务器，服务器用私钥解密。服务器用客户端给的密钥加密响应报文，发回给客户端，客户端用自己存的密钥解密。
忽略掉其他例如确定协议和版本号之类的环节，提炼出来的重要环节如下：
公私玥A用于非对称式加密，密钥B只用于普通的对称式加密。
简而言之就是这样，那么问题来了：你作为一个中间人，你没有服务器私钥A，是不能解密客户端发送的内容的，如果你没有客户端自己生成的密钥B，所以你也不能解密客户端发过去的内容的。
请注意：这两个私钥都是两端各自保存，而私钥A是只保存在服务器上，从不对外发送的。
结果就是，你收发的数据，他都能看到——————但是他不能解密，看不懂。
这只是最普通的劫持HTTP的方式，HTTPS就是为了解决题主所说的这个中间人攻击而产生的，然而题主并没有去理解HTTPS的工作原理，而用HTTP的原始思路继续去思考HTTPS，所以题主这个方法是完全不可行的。
继续往下想，或许有人会觉得：
如果你自己签发一对非对称式公私钥C，还有密钥D，然后作为一个中间人。在一开始的通信环节，用公私钥C替代公私钥A，用密钥D替代密钥B。这样分发给对应的服务器和客户端，这样他们发给自己的信息，自己都能解密。然后自己再用真正的公钥A把解密后的信息重新加密发给服务器骗取响应报文，把响应报文用密钥B（前面客户端用公钥C加密后，被中间人用私钥C解密的刀）重新加密发回给客户端骗取新的请求报文。
这样岂不是可以瞒天过海？
那么在图中所示的验证环节，因为你的证书是自己签发的，所以证书跟指纹拿去去系统里可信颁发机构的证书那一对，肯定对不上。
如果你要假冒其他机构颁发证书，因为你没有颁发机构的密钥，那么你颁发的证书，结果指纹肯定没办法对上，还是一样会报警。
系统信任的颁发机构一般都是权威的大机构，当然你也可以自己导入自己信任的机构的证书，用来验证签名。
如果要实现HTTPS下的中间人攻击，你应该让自己的根证书进入系统里，让自己成为裁判。
还有人就说了，我可以让用户回落到HTTP协议啊，中间人用HTTPS跟服务器通信，然后用HTTP跟客户端通信——要知道大部分用户在地址栏输入URL时，并没有指定协议的习惯，都是打www开头而不是打https://开头，能用HTTPS全是Web Server上80端口301 Location到HTTPS的功劳。
看起来似乎中间人充当了一个替换页面里HTTPS资源到HTTP的反向代理，好像可行性还是很高。
但是只要利用HSTS（HTTP Strict Transport Security，RFC6797）就可以解决这个问题。通过在HTTP Header中加入Strict-Transport-Security的声明，告诉浏览器在一定时间内必须通过HTTPS协议访问本域名下的资源。
这种情况下，只要用户曾经在安全网络环境下访问过一次某站，中间人在指定时间内也无法让其回落到HTTP。