双向 tls 校验,服务端校验的是客户端什么信息?

7 天前
 kyonn

如题,单向校验比较好理解,访问大部分公开网站都是这样的,只是客户端校验连接的服务器返回的证书是不是匹配准备连接的域名。因为只有掌握域名,才能拿到指定域名的证书。

mtls 双向校验过程中,服务器也要校验客户端是否合法。我的疑问时,这种情况下,服务器校验的是客户端什么信息呢?客户端也不具备域名,只能校验下客户端发送的证书是不是同一个 ca 签发的?

看网上的实践,客户端和服务端证书也是分别签发的,只不过用的是同一个 ca ,两者并没什么关联。那么服务端如何认定客户端的证书是合法的呢?要不要解完客户端证书后,再验证某个字段是不是在服务端的允许范围内?

2418 次点击
所在节点    程序员
31 条回复
irrigate2554
7 天前
客户端发送的证书是服务器签发后用户导入浏览器的,服务器端会校验客户端证书是否合法,你自签一个服务器端是不认的,理论上不仅可以做信任,也可以判明用户身份。
kyonn
7 天前
@irrigate2554
> 客户端发送的证书是服务器签发后用户导入浏览器的

这个指的是客户端证书也是由同一个 ca 签发的把。客户端证书跟服务端证书生成过程本身应该并没交集,比如客户端证书生成不需要用服务端证书作为输入?
kyonn
7 天前
@irrigate2554 还是说 服务端保留了 客户端证书类似私钥的部分,收到客户端证书后可以验证这个证书的有效性?
irrigate2554
7 天前
@kyonn 服务器端有个自签证书做 CA ,签发一堆客户端证书,用户拿到自己的客户端证书导入浏览器,浏览器询问用户是否发送证书给服务器,用户同意后服务器端收到客户端证书验证是不是自己的 CA 签发的,通过后允许访问网站功能也可以判明用户。

客户端证书不需要和服务器端 TLS 证书一样使用受信任的 CA ,一般都自签。
raptor
7 天前
简单说:单向校验只是客户端校验服务端是不是伪造的,如你自己所说,只有真正掌握域名的人才能创建相应的证书。
双向校验就是服务端也要校验客户端是不是伪造的,这时候客户端的证书就是服务端签发的,签发的时候服务端会做一些客户端身份校验,比如人脸识别之类,验证之后签发这个证书,以后所有通信以此证书为凭据,就不需要每次都校验了,比如银行之类的高安全要求情况。
fuzzsh
7 天前
extension OID
beyondstars
7 天前
1. 服务端验证客户端的证书是不是受信任(或者被信任)的 CA 签发的,当然这个 CA 可以是自建 CA ,你在 TLS 服务端明确制定信任什么 CA 即可。这是第一点,验签。

2. 当服务端能够证明客户端的证书属实是受信任的 CA 签发的之后,可以读取证书里边的信息,比如 Common Name ,但这一般是 Implementation-Specific 的,不同的 TLS 服务端实现(或者配置)可能会看不同的字段,x509 extension, exteded Usage 等等,都可以在验签之后开始判断。
ChicC
7 天前
xieranmaya
7 天前
类似于 u 盾
u 盾相当于实体证书,由用户的乙方签发给用户
比如银行 u 盾是银行签发给你的
工商局的 u 盾是工商局签发给公司的
kaneg
7 天前
首先确定是受信任的 CA 签发的,并且在有效期。其次是看 CN 和 OU 的字段,具体严格程度取决于服务器的设定。
guanzhangzhang
7 天前
同一套 ca 签署的才能走到后面的具体的 ACL 权限,一般用 CN OU 或者 x509 扩展字段内的信息做
julyclyde
7 天前
理论上双方不必须是同一个 CA 签发的

服务器端 SSL 开启双向验证的时候,服务器会向客户端出示“我想看哪个 CA 签发的证书”的那个 CA
然后客户端根据自己手里的证书看看有没有符合条件的,弹出一个窗口让用户选择
keepMyselfClam
7 天前
之前做过这样的项目. 简单来说验证的信息是可以根据不同常见的需求定制的(取决于服务器端的实现)

1.首先基础的信息验证包括:客户端证书的签发 CA 是否被服务器认可,证书是否在有效期内等.
2.在 1.的基础上可以进一步验证扩展(extension OID),如验证证书中包含的账户名或者部门名等.

几个常见问题:
Note1:客户端证书的签发 CA 是否要与服务器一致? 可以不一致.服务器可以指定若干个可信任的 CA 去接受他们签发的证书.
Note2:X.509 证书其实可以有很多扩展
sujin190
7 天前
你这第一条客户端校验服务端证书就理解不对吧,证书校验就是验证 ca 是否合法,只不过一般的 https 客户端默认使用一堆系统内置的可信 ca 来校验,任意通过即可,所以外加域名验证来确认服务器签发的证书是有效,但是客户端这个行为也是可配置的,如果你指定只信任特定 ca ,而这个 ca 签发服务器证书是有你控制的那就没必要校验域名了啊
而服务器这边开启客户端校验的时候默认行为就是需要添加需要信任的指定 ca 的吧,而且这个 ca 签发客户端证书也是你可控的,这不就好了,虽然这个行为也是可配置调整的,既然你都调整配置了,那你也完全可以指定继续校验客户端证书的其他信息啊,比如指定特定指纹才是有效的
DefoliationM
7 天前
不是同一个 CA ,没这限制,相当于服务端当客户端去验证而已,区别不大了。你对 tls 证书理解有很大的问题,tls 只保证传输层阶段的安全,不能当作应用的验证,你所说的证书合法,正常都是用系统自带的 ca 证书去验证而已,当然编程的时候完全可以自定义自签名 CA 证书(此处的自签名证书也可用来当作应用层的验证,因为证书是你自己生成的,不泄漏的话)。
whileFalse
7 天前
一般来说双向验证的场景下,服务端会白名单限制客户端证书指纹,或者至少是域名+CA
Andrue
7 天前
管理员手动或自动生成指定的客户端证书,只有安装有指定证书的设备才能访问指定 web 页面,具体访问策略由管理员配置的 web 服务器决定,核心就是管理员生成证书-管理员发放证书-用户导入证书这个流程
onikage
7 天前
trajon-go 是不是就是这种双向的?我两边都是自签的,client 端把 ca 倒入就 windows 就可以了。
Hanada
7 天前
你这个前提就是错的,没有规定客户端证书和服务端证书要用同一个 ca 签发。不同也是可以的,而且通常情况都应该是不同的,相同反而才有问题
scegg
7 天前
服务端验证客户端证书,首先需要证书被信任,也就是要么这个证书本身被信任,要么它的签发者在信任链上。至于这个证书的信任链与服务端证书是否一致是没有要求的。一般来说,这个信任过程会被 web 服务器处理,比如 nginx 。如果没有被信任,则不会被 web 服务器转发到后端。

在后端(用户自有代码),可以校验证书的信息,比如证书的 name 、编号、一些附加属性,这些都在签发时确定并包含在客户端证书内。一般来说可以将一些需要的信息作为附加属性加入客户端证书即可。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1147867

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX