SSL/TLS

http + ssl传输层 -> https

安全套接层

1、核心角色与文件
2、证书生成流程
- 2.1、生成CA根证书
- 2.2、生成服务端证书
- [2.3 生成客户端证书（双向认证）](#2.3 生成客户端证书（双向认证）)
[3、SSL/TLS 认证模式](#3、SSL/TLS 认证模式)
- [3.1、单向认证（默认 HTTPS）](#3.1、单向认证（默认 HTTPS）)
- 3.2、双向认证（mTLS）
4、认证关键点
5、对称数据加密
- 算法协商过程

1、核心角色与文件

文件	作用	归属方
ca.key	CA 根私钥，用于签发证书	证书颁发机构 (CA)
ca.crt	CA 根证书，用于验证签发证书的合法性	客户端/服务端
server.key	服务端私钥，用于 SSL 握手签名	服务端
server.crt	服务端证书（由 CA 签发），包含公钥+身份信息	服务端
client.key	客户端私钥（双向认证时使用）	客户端
client.crt	客户端证书（由 CA 签发）	客户端

2、证书生成流程

2.1、生成CA根证书

shell 复制代码

	# 生成 CA 私钥
	openssl genrsa -out ca.key 2048

	# 生成 CA 自签名根证书
	openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj "/CN=MyRootCA"

2.2、生成服务端证书

服务端证书 (server.crt) 必须由客户端信任的 CA（即 ca.crt）签发。

shell 复制代码

	# 生成服务端私钥
	openssl genrsa -out server.key 2048

	# 生成证书请求文件 (CSR)
	openssl req -new -key server.key -out server.csr -subj "/CN=www.example.com"

	# 用 CA 签发证书
	openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365

2.3 生成客户端证书（双向认证）

双向认证时，客户端证书 (client.crt) 必须由服务端信任的 CA 签发（通常也是 ca.crt）。

shell 复制代码

	# 生成客户端私钥
	openssl genrsa -out client.key 2048

	# 生成证书请求
	openssl req -new -key client.key -out client.csr -subj "/CN=ClientUser"

	# 用 CA 签发证书
	openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365

3、SSL/TLS 认证模式

证书验证本质是校验签发链是否通向信任的 CA。

3.1、单向认证（默认 HTTPS）

流程：
- 1、客户端验证服务端证书：
  - 校验 server.crt是否由 ca.crt签发。
  - 验证域名、有效期等。
- 2、服务端不验证客户端身份。

配置：

服务端 nginx

shell 复制代码

	# Nginx 配置示例
	# 自身认证
	ssl_certificate      server.crt;
	# 加密数据
	ssl_certificate_key  server.key;

客户端
- 需预装 ca.crt（否则浏览器会提示证书不受信）

3.2、双向认证（mTLS）

双向认证需要双方都配置信任链和证书。
流程：

1、客户端验证服务端证书（同单向认证）。

2、服务端验证客户端证书：
- 校验 client.crt 是否由 ca.crt 签发。
- 可选校验客户端证书的扩展字段（如用途）。

配置：

1、服务端 nginx

shell 复制代码

	ssl_verify_client on;          # 开启客户端验证
	ssl_client_certificate ca.crt; # 信任的 CA 证书

2、客户端

请求时需携带 client.crt 和 client.key。

shell 复制代码

	curl --cert client.crt --key client.key https://www.example.com

4、认证关键点

非对称加密仅用于身份认证和密钥交换：
服务端用 server.key 对握手消息签名，客户端用 server.crt 中的公钥验证签名。
双方协商出对称密钥（如 AES），后续通信使用对称加密。
数据加密由对称密钥完成，非对称加密不直接加密业务数据。

5、对称数据加密

算法协商过程

ClientHello：客户端发送支持的密码套件列表
ServerHello：服务器从客户端支持的列表中选择一个双方都支持的密码套件
密钥交换：通过非对称加密（RSA、ECSHE）协商出预主密钥(Pre-Master
Secret)，最终生成会话密钥（Session Key）.
- 特性：
  - 密钥保密性：
    - 会话密钥动态生成：每次 TLS连接都会生成唯一的会话密钥，仅在内存中存在，不会通过网络传输。
    - 密钥交换安全性：
      非对称加密（RSA、ECDHE）保护预主密钥的传输。
      前向保密（Prefect Forward Secrecy,PFS）:使用ECDHE等算法时，每次会话的临时密钥在连接结束后销毁，即使服务器私钥泄露，历史会话也无法解密。
  - 加密算法的强度：
    - AES安全性：AES是 NIST认证的对称加密算法，目前无已知有效攻击手段。
    - 加密模式优化：现代 TLS适用 AES-GCM等认证加密模式，同时保证机密性和完整性。
  - 协议防护机制：
    - 防重放攻击：通过随机数和序列号确保数据包不被重复使用
    - 完整性校验：HMAC或 AEAD(如 GCM)防止数据被篡改