Web安全 - 01SSL、TLS、HTTPS、证书和 CA
文章目录
- 01 小白基础：SSL、TLS、HTTPS、证书和 CA
- 1. SSL、TLS、HTTPS 是什么关系
- 1.1 SSL
- 1.2 TLS
- 1.3 HTTPS
- 2. 一次 HTTPS/TLS 连接做了什么
- 3. 证书到底是什么
- 4. CA 和证书链怎么理解
- 5. TrustStore 和 KeyStore 是什么区别
- 5.1 TrustStore：我信谁
- 5.2 KeyStore：我是谁
- 6. Hostname Verification 是什么
- 7. 密码套件是什么
- 8. 为什么 Java 接国密不能只用默认 JDK
- 9. 常见误区
- 误区 1：有证书就能连
- 误区 2：关闭证书校验最省事
- 误区 3：`https://` 就一定是普通 TLS
- 误区 4：服务端证书和客户端证书是一回事
- 误区 5：证书链过了，业务就一定成功
- 10. 本篇小结
01 小白基础：SSL、TLS、HTTPS、证书和 CA
这一篇不讲国密细节，先把最基础的 SSL/TLS/HTTPS 讲清楚。你只有先知道普通 HTTPS 怎么工作，后面理解 TLCP、国密双证书、TrustStore、KeyStore 才不会乱。
1. SSL、TLS、HTTPS 是什么关系
1.1 SSL
SSL 是早期的安全传输协议名字。现在严格说 SSL 已经过时了，但很多人仍然习惯把“HTTPS 证书”“TLS 通道”“TLCP 通道”统称成“SSL”。
所以你听到“国密 SSL”，不要急着按字面理解。它很可能只是业务方的习惯说法。
1.2 TLS
TLS 是现代互联网广泛使用的安全传输协议。普通 HTTPS 大多跑在 TLS 上。
TLS 解决三个核心问题：
| 问题 | TLS 怎么解决 |
|---|---|
| 我怎么知道对面真的是那个服务器？ | 证书 + CA 信任链认证服务端身份 |
| 网络中间人能不能看到内容？ | 握手协商出会话密钥，后续数据加密 |
| 数据能不能被篡改？ | 记录层带完整性保护，篡改会被发现 |
RFC 8446 对 TLS 的目标描述可以概括为：在可靠、有序的传输之上，为通信双方建立具备认证、保密性和完整性保护的安全通道。原文见 RFC 8446。
1.3 HTTPS
HTTPS = HTTP + TLS。
HTTP 负责业务语义：
POST /dd-server/v1/file/upload Content-Type: multipart/form-data Content-Meta: {...}TLS 负责安全通道：
先握手 → 验证证书 → 协商密钥 → 加密 HTTP 请求和响应所以你在代码里看到 URL 仍然是：
https://xxx:xxxx/xxxx/v1/file/upload并不代表它一定是普通国际 TLS。对 TLCP 客户端来说，HTTP 库仍然用https://作为“我要走安全套接字”的入口，但底层SSLContext可以换成TLCPv1.1。
2. 一次 HTTPS/TLS 连接做了什么
把 TLS 握手简化成小白版：
客户端：你好，我支持这些协议版本、密码套件、签名算法。 服务端：我选择其中一种协议和套件，这是我的证书。 客户端：我检查证书是不是可信、有没有过期、是不是这个域名。 双方：通过非对称算法协商出一个只有双方知道的会话密钥。 双方：之后的 HTTP 数据都用会话密钥加密传输。关键词解释：
- 协议版本：比如 TLS 1.2、TLS 1.3、TLCPv1.1。
- 密码套件：一组算法组合，告诉双方“用什么方式认证、交换密钥、加密、做完整性保护”。
- 证书：服务端拿来证明“我是谁”的文件。
- CA：签发证书的机构。
- 会话密钥：真正用来加密大量业务数据的对称密钥。
3. 证书到底是什么
证书可以理解为一张“服务器身份证”。它里面通常包含：
| 字段 | 含义 |
|---|---|
| Subject | 证书主体，比如这个证书发给谁 |
| Issuer | 谁签发了这个证书 |
| Serial Number | 证书序列号 |
| Not Before / Not After | 生效时间和过期时间 |
| Public Key | 公钥 |
| Signature Algorithm | 证书签名算法 |
| SAN / CN | 域名或 IP 匹配信息 |
服务端保存的是：
服务端证书 + 服务端私钥客户端通常只拿到：
CA 根证书 / 中间 CA 证书为什么客户端不应该拿服务端私钥？因为私钥是身份凭据，泄露就等于身份被别人冒用。
4. CA 和证书链怎么理解
现实世界里，你不会见到某个人就认识他，但你可能相信公安机关签发的身份证。
证书也是类似：
ROOTCA（根CA） ↓ 签发XXXXSM2CA（中间CA） ↓ 签发 server.example.com（服务端证书）客户端如果信任ROOTCA，并且能验证XXXSM2CA是ROOTCA签的、服务端证书是BeijingSM2CA签的，就能建立一条信任链。
本工程默认信任链是：
trust-certificates:-classpath:certs/ROOTCA.cer-classpath:certs/XXXXSM2CA.cerclasspath 版本会被打进 jar，适合默认演示。生产环境更建议放在外部安全路径，用file:/...配置。
5. TrustStore 和 KeyStore 是什么区别
这两个词非常容易混。
5.1 TrustStore：我信谁
TrustStore 存的是“我信任的 CA 证书”。
客户端校验服务端证书时，会问：
这个服务端证书能不能一路链到我的TrustStore里的某个可信CA？本工程的TlcpSslContextFactory会把配置里的.cer文件读出来，放进一个临时的 JKS TrustStore，再交给 KonaSSL 的TrustManagerFactory。
5.2 KeyStore：我是谁
KeyStore 存的是“我自己的证书 + 私钥”。
只有服务端要求客户端也证明身份时，客户端才需要 KeyStore。也就是常说的双向认证、mTLS、客户端证书认证。
本工程默认不配置客户端 KeyStore：
client-key-store:path:如果填了：
client-key-store:path:file:/secure/client.p12type:PKCS12password:changeitkey-password:changeit客户端握手时就可以向服务端发送自己的证书，并用私钥完成证明。
6. Hostname Verification 是什么
证书链可信，只说明证书是某个可信 CA 签的；还要确认这个证书是不是发给你正在访问的主机。
比如你访问：
https://api.example.com证书里应该包含：
DNS:api.example.com如果你访问：
https://192.168.8.101证书里最好包含：
IP:192.168.8.101否则 Hostname Verification 会失败。
本工程默认：
hostname-verification-enabled:false这是为了兼容很多内网 TLCP 服务端只给 IP 访问、证书里又没配 IP SAN 的联调环境。
但是生产环境建议：
- 让服务端证书 SAN 正确包含域名或 IP；
- 把
hostname-verification-enabled改成true； - 用域名访问，而不是裸 IP。
7. 密码套件是什么
密码套件是一组算法组合。普通 TLS 里你可能见过：
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256国密 TLCP 里本工程默认使用：
TLCP_ECC_SM4_GCM_SM3 TLCP_ECC_SM4_CBC_SM3按名字拆：
| 片段 | 大概含义 |
|---|---|
| TLCP | 用 TLCP 协议 |
| ECC / ECDHE | 密钥交换/认证相关模式 |
| SM4 | 对称加密算法 |
| GCM / CBC | SM4 的工作模式 |
| SM3 | 杂凑/完整性相关算法 |
新手先记住：客户端和服务端必须至少有一个共同支持的密码套件。没有交集，握手会失败。
8. 为什么 Java 接国密不能只用默认 JDK
标准 JDK 的 JSSE/JCA 对普通 TLS 支持很好，但 TLCP 和国密算法不是默认全覆盖。
本工程用了 Tencent Kona SM Suite：
KonaCrypto：提供 SM2/SM3/SM4 算法；KonaPKIX：提供国密证书解析、KeyStore 和证书链处理；KonaSSL：提供 TLCP/国密 TLS 相关 SSL 能力。
也就是说，Java 代码里不是直接：
SSLContext.getInstance("TLS")而是：
SSLContext.getInstance("TLCPv1.1","KonaSSL")这就是国密接入和普通 HTTPS 接入最重要的差别之一。
9. 常见误区
误区 1：有证书就能连
不一定。你需要的是正确的 CA 链、正确的协议、正确的密码套件、正确的 Provider。
误区 2：关闭证书校验最省事
短期可能“能连”，长期是安全事故。联调时可以临时关闭 hostname verification，但不要跳过 CA 校验，更不要写“信任所有证书”的 TrustManager。
本工程没有信任所有证书，而是仍然要求配置trust-certificates。
误区 3：https://就一定是普通 TLS
不是。URL scheme 只是 HTTP 客户端入口。底层用普通 TLS 还是 TLCP，取决于SSLContext和 socket 工厂。
误区 4：服务端证书和客户端证书是一回事
不是。
- 服务端证书：服务端证明自己。
- 客户端证书：客户端证明自己。
- CA 证书：客户端或服务端用来验证对方证书链。
误区 5：证书链过了，业务就一定成功
TLS/TLCP 只保证安全通道。业务层还可能因为路径、请求头、multipart 字段名、Content-Meta、鉴权参数失败。
所以排错时要分层：
网络能通？ ↓ TLCP 握手成功？ ↓ HTTP 发出去了？ ↓ 业务响应成功？10. 本篇小结
你现在应该能解释：
- SSL 是旧名，TLS 是现代安全传输协议，HTTPS 是 HTTP over TLS。
- TLS 主要提供认证、保密性、完整性。
- 证书链用于证明服务端身份，TrustStore 表示“我信任谁”。
- KeyStore 表示“我是谁”，只有双向认证时客户端才需要。
- Hostname Verification 是检查证书主体和访问地址是否匹配。
- 国密 TLCP 在 Java 里需要 Kona 这类 Provider，不能只靠默认 JDK。
下一篇进入标准背景，解释国际 TLS、RFC 8998 和中国 TLCP 到底是什么关系。