V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
kyonn
V2EX  ›  程序员

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

  •  
  •   kyonn · 6 天前 · 2389 次点击

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

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

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

    31 条回复    2025-07-30 14:04:09 +08:00
    irrigate2554
        1
    irrigate2554  
       6 天前   ❤️ 1
    客户端发送的证书是服务器签发后用户导入浏览器的,服务器端会校验客户端证书是否合法,你自签一个服务器端是不认的,理论上不仅可以做信任,也可以判明用户身份。
    kyonn
        2
    kyonn  
    OP
       6 天前
    @irrigate2554
    > 客户端发送的证书是服务器签发后用户导入浏览器的

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

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

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

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

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

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

    在后端(用户自有代码),可以校验证书的信息,比如证书的 name 、编号、一些附加属性,这些都在签发时确定并包含在客户端证书内。一般来说可以将一些需要的信息作为附加属性加入客户端证书即可。
    zizon
        21
    zizon  
       6 天前
    >这种情况下,服务器校验的是客户端什么信息呢
    校验 client 是不是真的事 claim 的那个 client,而不是假冒的.

    >那么服务端如何认定客户端的证书是合法的呢?要不要解完客户端证书后,再验证某个字段是不是在服务端的允许范围内?
    你自问自答的是一种方式.

    实际上,mTLS 更多的是为了锁定连接身份.
    没有 client certificate 的话,一个连接的所属权纯粹依赖网络协议里 encode 的信息.
    而这个信息是足以保证两个不同的链接是真的由同一个实体发起的.

    client 证书就解决了证明不同连接的发起确实是属于同一实体.

    跟 client 校验 server 确实是目标 server 一个道理,不过方向相反而已.
    julyclyde
        22
    julyclyde  
       5 天前
    @whileFalse 客户端证书哪来的域名?
    iOCZS
        23
    iOCZS  
       5 天前
    如何解决伪客户端盗用证书的问题呢?
    julyclyde
        24
    julyclyde  
       4 天前
    @iOCZS 伪客户端如果有本事盗,那服务器就承认,没必要解决
    whileFalse
        25
    whileFalse  
       3 天前 via Android
    @julyclyde 服务端证书哪儿来的域名客户端证书就哪儿来的域名
    julyclyde
        26
    julyclyde  
       3 天前
    @whileFalse 人傻就该多读书
    whileFalse
        27
    whileFalse  
       3 天前 via Android
    @julyclyde 我司双向 https 是我配的
    julyclyde
        28
    julyclyde  
       3 天前
    @whileFalse
    把特例就当成普适
    这正是我让你多读书的原因
    whileFalse
        29
    whileFalse  
       3 天前 via Android
    @julyclyde 我司双向 https 就是我配的。我们是服务器对服务器的回调场景。
    没见识就老实听别人说话,嘲讽你妈呢。
    julyclyde
        30
    julyclyde  
       3 天前
    @whileFalse
    https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate
    Syntax: ssl_client_certificate file;
    Default: —
    Context: http, server
    Specifies a file with trusted CA certificates in the PEM format used to verify client certificates and OCSP responses if ssl_stapling is enabled.
    The list of certificates will be sent to clients. If this is not desired, the ssl_trusted_certificate directive can be used.
    whileFalse
        31
    whileFalse  
       2 天前 via Android
    @julyclyde 你想表达什么呢?
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2613 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 04:59 · PVG 12:59 · LAX 21:59 · JFK 00:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.