ssl/tls证书解决加密与身份可信两大问题：非对称加密用于安全交换对称密钥，后续通信采用高效对称加密；信任链依赖浏览器内置根证书，通过逐级验证签名确保证书合法有效。
从通信机制和密码学基础入手，比直接啃协议文档更有效。重点不是记住每一步，而是理解“为什么这样设计”。
先搞懂两个核心目标
SSL/TLS证书解决的是两个根本问题：一是让数据传过去别人看不懂（加密），二是确认对面真的是它声称的那个网站（身份可信）。所有技术细节都围绕这两点展开。
- 加密靠密钥分工：非对称加密（如RSA、ECC）只在握手阶段用，用来安全传递一个临时的对称密钥；之后全部用对称加密（如AES）传输数据——因为快，且足够安全。
- 可信靠信任链：浏览器内置了一堆根证书（比如DigiCert、Let’s Encrypt的根），它们是整个信任体系的起点。服务器证书必须能顺着中间证书一路回溯到某个浏览器认的根证书，才算合法。
动手拆解一次真实握手
不用写代码，用工具抓一次HTTPS连接就能看到全过程。比如用Wireshark过滤tls.handshake，或用openssl s_client -connect example.com:443 -servername example.com连一个网站，观察输出里的Server certificate、Verify return code等字段。
- 你会看到客户端先发支持哪些加密算法、随机数；
- 服务器回传证书、选中的算法、自己的随机数；
- 客户端验证证书是否过期、域名是否匹配、签名能否被根证书验证；
- 验证通过后，生成预主密钥，用服务器公钥加密传过去；
- 双方用三个随机数+预主密钥算出同一个会话密钥，后续全靠它加密。
对照证书文件看结构
拿一个.pem或.crt文件，用命令openssl x509 -in cert.pem -text -noout打开，重点看这几项：
-
Subject：证书给谁发的，比如
CN=example.com或SANs: DNS:api.example.com, DNS:www.example.com； -
Issuer：谁签的，比如
O=Let's Encrypt, CN=R3； - Validity：有效期起止时间；
- Signature Algorithm：用什么算法签的名（如sha256WithRSAEncryption）；
-
X509v3 extensions：有没有
CA:FALSE（说明不是根/中间证书）、Key Usage是否包含keyEncipherment等。
区分自签和CA签发的本质差异
自己用OpenSSL生成的证书和Let’s Encrypt发的证书，技术格式几乎一样，差别只在“谁盖的章”。
- 自签名证书的
Issuer和Subject相同，没有上级背书，浏览器不认； - CA签发的证书，
Issuer是受信机构，它的公钥早已预装在操作系统或浏览器里； - 验证时，客户端用Issuer的公钥去解密证书里的签名，再比对哈希值——这步能过，才说明证书没被篡改、且来源可信。
