使用证书进行SSL身份验证：证书是否应具有主机名？
问题的快速版
Gmail，TD（加拿大银行），皇家银行（加拿大银行）都使用ssl。当你检查他们的证件他们都有使用证书进行SSL身份验证：证书是否应具有主机名？
Common Name (CN) mail.google.com
或者更一般地说：
Common Name (CN) <url>
难道这需要防止中间人攻击？
摘要
JBoss允许客户端和服务器使用证书和ssl进行身份验证。有一件看起来很奇怪的事情是，你不需要在证书上给你的主机名。
我认为这意味着如果服务器B在您的信任库中，Sever B可以伪装成他们想要的任何服务器。
（以及类似：如果客户B在您的信任...）
我失去了一些东西在这里？
认证步骤
Client Server
=================================================================================================
1) Client sends Client Hello
ENCRIPTION: None
- highest TLS protocol supported
- random number
- list of cipher suites
- compression methods
2) Sever Hello
ENCRIPTION: None
- highest TLS protocol supported
- random number
- choosen cipher suite
- choosen compression method
3) Certificate Message
ENCRIPTION: None
-
4) ServerHelloDone
ENCRIPTION: None
5) Certificate Message
ENCRIPTION: None
6) ClientKeyExchange Message
ENCRIPTION: server's public key => only server can read
=> if sever can read this he must own the certificate
- may contain a PreMasterSecerate, public key or nothing (depends on cipher)
7) CertificateVerify Message
ENCRIPTION: clients private key
- purpose is to prove to the server that client owns the cert
8) BOTH CLIENT AND SERVER:
- use random numbers and PreMasterSecret to compute a common secerate
9) Finished message
- contains a has and MAC over previous handshakes
(to ensure that those unincripted messages did not get broken)
10) Finished message
- samething
Sever的谁知
客户端具有发送证书的公钥（步骤7）
-
客户端的证书是有效的，因为：
- 已经由CA（威瑞信）签署
- 它已经自签名，但它是在服务器的信任
它不是一个重放攻击，因为大概是随机数（步骤1或2）与每个消息一起发送
客户端知道
服务器为发送证书（步骤6步骤8）公钥
-
服务器的证书是有效 因为无论：
- 已经由CA（Verisign所签发）
- 已自签名，但它是在客户端的信任
它不是一个重放攻击，因为presu马布利的随机数（步骤1或2） 与每个消息
潜在问题
-
发送假设客户机的truststore中有证书：
- 服务器A
- 服务器B（恶苹果）
服务器A主机名www.A.com
服务器B主机www.B.com
假设：客户端试图连接到服务器A，但服务器B在中间推出一个男人攻击。
-
由于服务器B：
- 具有将被发送到客户端证书的公钥
- 有一个“有效证书”（在信任一个证书）
- 由于：
- 证书中没有主机名字样
看起来服务器B可以很容易地假装为服务器A.
有什么，我失踪？
你能指出一些文字说JBoss在证书中不需要主机名，还是仅仅是你的观察？我认为'主机名'是指通用名称（CN）或可分辨名称（DN）？
通常应用程序应该检查的X.509证书：
有效的日期范围
用法（例如，服务器授权）
链接到受信任根
CN ==目标的DNS名称主机（它可能是另一个名字，而不仅仅是DNS）
没有被撤销（使用CRL或OCSP）
从技术上讲，一个应用程序可以选择忽略任何这些，只是表示ŧ帽子一切都很好与证书....但这是不好的:)
嗨迈克尔，我按照这个教程：http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/Server_Configuration_Guide/html/Using_JBoss_Login_Modules-BaseCertLoginModule.html。它没有明确说明主机名不需要在生成的证书中，但是它也没有声明。我现在有“认证和加密”的东西，但我只是意识到它没有服务器的主机名。这会成为一个安全漏洞吗？有什么方法可以强制它检查主机名。这是必要的吗？ – sixtyfootersdude 2010-04-12 13:47:16
嘿，如果你没有检查'另一端'的名字，那么你会受到中间人攻击。如果您查看链接的文档，您会看到他们在证书中有名称，这是CN =和OU =引用。 – 2010-04-12 22:47:43
CN == DNS检查不是SSL/TLS的严格组成部分。相反，它是是否信任某个站点的特定证书的政策的一部分。在某些情况下，这是一件完全合理的事情（但您担心某个CA默认信任的某个地方是否会欺骗为服务器签名虚假证书），而在其他情况下则不然（特别是当您只信任单个，限制性CA;对于客户端不是标准浏览器的Intranet应用来说，这是一种可行的方法）。 – 2010-04-13 13:50:55
我想你错过了一些东西，但我不知道如果我理解你的推理。
但是，当服务器B试图在中间攻击中启动一个人时，您说它有一个公钥。这是真的，但要建立一个ssl连接，你还应该有一个属于该公钥的私钥。此外，所使用的证书与DNS名称（在https的情况下）相结合。因此，一个客户端尝试连接到A，他在www.a.com中键入。既然我们假设B不知道A的私钥，他将拥有另一个密钥对。他永远不会收到来自主要CA的有效（即可信）证书，该证书与他不属于的域相关联。
因此，B永远不会得到一个通用名称的证书www.A.com，因此，B不能在中间人攻击中执行一个人。
这看起来不像一个编程问题。投票转移到服务器故障。 – 2010-04-08 19:04:40
我认为这是与算法有关...？ – sixtyfootersdude 2010-04-08 19:28:09
@david，是的这是一个编程问题。 ServerFault上的人员不完全理解安全因为他们不是程序员。 – rook 2010-04-08 19:29:47