我正在查看一些通过HTTPS进行安全通信而继承的客户端代码，看来它没有在检查服务器证书中的通用名称(例如，" CN =" example.com"")与实际的URL这可能是有意的，因为我们的客户端应用需要与各种环境进行对话，因此在联系初始门户(例如example.com/main)并且用户选择了环境后，该应用会重定向到特定IP因此所有以后的请求看起来都类似于" http://127.0.0.1/page"。

但是，作为SSL新手，我不确定禁用此检查的含义。我的第一个反应是，进行某种中间人攻击会更容易，因为其他人可以只复制我们的证书并假装成为我们的服务器之一。但是，如果我们进行通用名称检查，那么无论如何我们都可以使用自定义DNS设置执行相同的操作，因此它似乎实际上并没有给我们带来任何好处。是否还有其他攻击使我们敞开大门？

谢谢

解决方案

为了对"自定义DNS设置"执行相同的操作，攻击者应利用DNS服务器(我们或者客户端的DNS服务器)将example.com指向他控制的IP，而不是仅复制证书。如果可能，我将所有特定的应用程序创建为example.com的子域，并使用通配符证书(* .example.com)来验证CN。

其他人不能只是复制证书并使用它，因为他们没有私钥。

如果我们不检查证书的CN是否与域名不匹配，则他们可以简单地创建自己的证书(并由受信任的CA签名以使其看起来有效)，代替证书，然后执行男子在中间攻击。

另外，我们需要检查证书是否来自受信任的CA。确保我们仅在实际控制该域的情况下才能获得CN =证书，这是CA的工作。

如果我们跳过这两项检查中的任何一项，那么我们就有遭受MITM攻击的危险。

如果我们对客户端有足够的控制权，请参见此答案以获取另一种可行的方法。

如果控制客户端代码，则可以将受信任的CA限制为我们自己的CA。然后，域检查的重要性就变得不那么重要了，任何一台服务器都可以假装为另一台服务器。

如果我们不控制客户端代码，则可以使用由受信任的CA签名的证书代替证书。

主机名验证(验证CN部分)可确保连接的另一端(服务器)在我们在地址栏中键入的域名存在SSL证书问题。通常，攻击者将无法获得此类证书。

如果我们不验证主机名部分，则有人(有人坐在请求通过的任何路由器或者代理通过)可能会在中间攻击中发动袭击。或者有人可以利用某些DNS攻击。

$ 0.02：不建议将CN用作主机名，而应使用X.509主题备用名。