浙江
你有没有想过一个问题：在网络上，你到底是怎么证明"你是你"的？
登录网站要输密码，访问银行要插U盾，微信支付给商户发回调要验签——这些场景背后，其实是同一套逻辑在换着花样升级：身份认证。今天就把这条技术线从头捋一遍，从密码到数字证书，再到云原生时代几乎标配的 mTLS。
第一步：密码，最朴素的方案
最早期的方案就是你最熟悉的用户名+密码。前提假设是：密码全世界只有你自己知道，你能给出正确密码，就默认你是你。
但密码有个硬伤——你得把密码"告诉"对方，对方才能验证，所以它只适合权威机构和普通用户之间（比如登录银行App）。为了加固，后来又加了 2FA（双因素认证）、MFA（多因素认证），短信验证码、动态口令都属于这类，相当于"密码+设备"双重证明。
第二步：密钥对，把公钥撒出去
密码这条路走不远，就得换思路：非对称加密。ECC（椭圆曲线密码）这类算法会生成一对密钥——私钥自己藏好，公钥公开给全世界。
举个例子，我用私钥加密一条信息发出去，所有人都能用我的公钥解开。能解开，就证明这条信息确实是我发的——既保证内容没被篡改，也顺带完成了身份认证。网站部署 HTTPS 用的就是这套：服务器把证书和公钥交给访问者，访问者解密验证后，才确认"这网站是真的，不是钓鱼的"。
第三步：中间人攻击，逼出了数字证书
但公钥本身有个大坑：你怎么知道这个公钥真的是银行的？DNS 可能被劫持，网络可能被伪造，中间人完全可以伪装成对方跟你对话，再塞给你一个假的"银行公钥"——这就是经典的中间人攻击。
解决方案就是数字证书。证书相当于网络世界的身份证，由 CA（证书颁发机构）这个大家都信任的权威机构签发：Alice 把自己的信息和公钥打包成 CSR 发给 CA，CA 线下核实身份后，用自己的私钥签名生成证书。Bob 拿到证书，用 CA 的公钥解开，就能确认 Alice 的公钥是真的。CA 还能给下级 CA 发证，一层套一层形成证书链，最顶层的叫根证书——这就是你电脑里那一堆"受信任的根证书颁发机构"的来历。
第四步：自己动手，openssl 四步生成证书
不是所有场景都要去找大 CA。企业内部完全可以自建"小王国"，用 openssl 自己签发证书：先给 CA 生成自签证书和私钥，再生成 Alice 的私钥和 CSR（签名请求），最后用 CA 私钥给 Alice 签出证书。核心命令就这几条：
openssl req -newkey rsa:2048 -x509 -out ca.crt -keyout ca.keyopenssl genrsa -out alice.key 2048openssl req -new -key alice.key -out alice.csropenssl x509 -req -in alice.csr -CA ca.crt -CAkey ca.key -out alice.crt
跑完这四步，你就拥有一套自签发的证书体系了，内网服务之间互信完全够用。
第五步：mTLS，双向认证
前面说的都是单向认证——确保你访问的是真网站。但很多场景需要双向：比如微信支付通知商户"支付完成"，微信要确认商户是真的，商户也要确认来通知的是微信本人，两边都得验。
mTLS（双向 TLS）就是干这个的。普通 TLS 只有服务器出示证书，mTLS 则是客户端和服务器各持一张证书，互相验证通过后才建立加密连接。云原生和零信任架构里，mTLS 基本是服务间通信的标配。
那为什么互联网没全面升级成 mTLS？原因很现实：给几十亿终端用户分发、管理证书，成本高到不现实。但在组织内部这种可控范围内，mTLS 就是性价比极高的选择。
你在项目里用过 mTLS 或者自签证书吗？踩过什么坑，评论区聊聊。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
