我知道对于MTLS，双方，客户端和服务器交换证书。这些证书应该由双方都可以信任的CA签名，以便验证证书。我的问题是，MTLS是否也意味着除了验证证书（如果CA是可信的，叶证书也是可信的），任何一方（服务器或客户端）还可以做一些额外的检查，如主机名检查或连接到服务器的客户端是否在批准的可信实体列表中？有人能告诉我mTLS规范吗？mTLS的开销是什么？
js81xvg61#
除了EJP所说的“MTLS”术语之外，TLS 1.2 specification对检查哪些信息以及以何种方式检查没有严格的要求。由接收方决定出示的证书是否可信。这意味着，例如，服务器可以只接受属于拥有服务器的公司的CA颁发的证书。这就是客户-银行访问系统通常的工作方式-它们只接受银行签发的证书，而且这种证书的通用名称必须与网上表格中提供的用户名相符。双方都可以自由检查证书中的任何信息，包括直接比较公钥哈希（因此，无论其他证书属性中包含什么，只有特定的密钥对才有效）。
vc9ivgsu2#
关于此主题的最新RFC是：https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/这是对OAuth 2.0的扩展本文档的目的是定义TLS证书在替换客户端ID和密码（又称客户端凭据）的上下文中的使用机制该标准建立了两种机制，即TLS证书如何用作客户端凭证，以及相关的令牌流和属性。这方面的一般总结如下：(a)授权服务器：根据PKI（由有效的根签名）检查证书RFC没有定义选项，但它们是非常不言自明的，取决于用例。但它可以是（1）证书由受信任的根签名，并且没有被吊销，（2）基于某种逻辑单独识别每个证书。(b)资源服务器检查令牌和客户端证书（客户端凭据或CC），并在基础TLS会话中使用。请注意，TLS层没有关于证书或其来源的验证检查，所有检查都在应用层执行。因此，资源服务器应配置TLS堆栈，使其不验证客户端在握手期间提供的证书是否由受信任的CA证书签名。这种机制在某些GDPR上下文中变得特别有趣，因为它使客户端和服务器之间无法共享令牌。总的来说，这是一个很好的隐私功能，并提高了安全性。
jaql4c8m3#
mTLS可通过向所有参与方颁发CA证书并将这些证书添加到所有通信参与方来实现，这是一种访问控制列表。任何在应用的信任存储中拥有CA证书的人都可以进行连接。然而，在https连接的情况下，信任系统与TLS相同--您可以从同一个CA颁发多个证书，并将根CA证书添加到应用的信任存储区。它将信任从同一个根颁发的所有证书。这可以说更容易设置，因为您只需添加应用自己的证书和CA根。但是，如果您想要撤销证书，就变得有点复杂了。我在这里写了一个生成证书的指南：
wfauudbj4#
第一：服务器和客户端证书必须使用相同的CA证书和密钥构建参见：https://github.com/ysimonx/mtls-ssl-generator/blob/main/generate_certificates.sh因此，您必须在两端存储CA证书：
https: { requestCert: true, rejectUnauthorized: true, key: fs.readFileSync("./certificates/server/serverKey.pem"), cert: fs.readFileSync("./certificates/server/serverCrt.pem") , ca: [fs.readFileSync("./certificates/ca/caCrt.pem")] }
（fastify nodejs https自签名证书服务器示例）
curl -k --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
（参数-k：不根据CA授权验证服务器证书）或
curl --cacert ./certificates/ca/caCrt.pem --cert ./certificates/client/clientCrt.pem --key ./certificates/client/clientKey.pem https://localhost:3000/
如果希望客户端与服务器使用的正确CA证书匹配
68bkxrlz5#
没有“MTLS规范”，因为没有“MTLS”这样的东西，这是很好的理由。你只是编造了它。***TLS**规范， 包括 * 相互验证，可以在RFC 2246中找到修订版。TLS API应该使对等证书链对应用程序可用，以便它可以执行任何它喜欢的附加检查。“MTLS”，只要它存在，指的是用于 * 多路复用 * TLS的因特网草案。
5条答案
按热度按时间js81xvg61#
除了EJP所说的“MTLS”术语之外，TLS 1.2 specification对检查哪些信息以及以何种方式检查没有严格的要求。
由接收方决定出示的证书是否可信。这意味着，例如，服务器可以只接受属于拥有服务器的公司的CA颁发的证书。这就是客户-银行访问系统通常的工作方式-它们只接受银行签发的证书，而且这种证书的通用名称必须与网上表格中提供的用户名相符。
双方都可以自由检查证书中的任何信息，包括直接比较公钥哈希（因此，无论其他证书属性中包含什么，只有特定的密钥对才有效）。
vc9ivgsu2#
关于此主题的最新RFC是：
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/这是对OAuth 2.0的扩展
本文档的目的是定义TLS证书在替换客户端ID和密码（又称客户端凭据）的上下文中的使用机制
该标准建立了两种机制，即TLS证书如何用作客户端凭证，以及相关的令牌流和属性。
这方面的一般总结如下：
(a)授权服务器：根据PKI（由有效的根签名）检查证书RFC没有定义选项，但它们是非常不言自明的，取决于用例。但它可以是（1）证书由受信任的根签名，并且没有被吊销，（2）基于某种逻辑单独识别每个证书。
(b)资源服务器检查令牌和客户端证书（客户端凭据或CC），并在基础TLS会话中使用。请注意，TLS层没有关于证书或其来源的验证检查，所有检查都在应用层执行。因此，资源服务器应配置TLS堆栈，使其不验证客户端在握手期间提供的证书是否由受信任的CA证书签名。
这种机制在某些GDPR上下文中变得特别有趣，因为它使客户端和服务器之间无法共享令牌。
总的来说，这是一个很好的隐私功能，并提高了安全性。
jaql4c8m3#
mTLS可通过向所有参与方颁发CA证书并将这些证书添加到所有通信参与方来实现，这是一种访问控制列表。任何在应用的信任存储中拥有CA证书的人都可以进行连接。
然而，在https连接的情况下，信任系统与TLS相同--您可以从同一个CA颁发多个证书，并将根CA证书添加到应用的信任存储区。它将信任从同一个根颁发的所有证书。这可以说更容易设置，因为您只需添加应用自己的证书和CA根。但是，如果您想要撤销证书，就变得有点复杂了。
我在这里写了一个生成证书的指南：
wfauudbj4#
第一：服务器和客户端证书必须使用相同的CA证书和密钥构建
参见：https://github.com/ysimonx/mtls-ssl-generator/blob/main/generate_certificates.sh
因此，您必须在两端存储CA证书：
（fastify nodejs https自签名证书服务器示例）
（参数-k：不根据CA授权验证服务器证书）
或
如果希望客户端与服务器使用的正确CA证书匹配
68bkxrlz5#
没有“MTLS规范”，因为没有“MTLS”这样的东西，这是很好的理由。你只是编造了它。***TLS**规范， 包括 * 相互验证，可以在RFC 2246中找到修订版。
TLS API应该使对等证书链对应用程序可用，以便它可以执行任何它喜欢的附加检查。
“MTLS”，只要它存在，指的是用于 * 多路复用 * TLS的因特网草案。