企业官网建设流程全解析

一、基础概念区分

SSL 和 TLS

SSL（Secure Socket Layer）是早期的安全协议，由网景公司开发。SSL 1.0、2.0、3.0 都存在严重安全漏洞，已经全部废弃。 TLS（Transport Layer Security，传输层安全）是 SSL 的继任版本，本质是SSL 的标准化改名。现在我们使用的全部都是 TLS，日常口语说的 SSL 证书，只是习惯叫法，证书里用的是 TLS。 版本：TLS1.0、1.1 淘汰；目前广泛部署 TLS1.2、TLS1.3。

HTTPS

HTTP 本身只是明文文本协议，直接在网络传输，任何中间节点（路由器、网关）都可以看到完整内容，也可以随意修改报文。HTTPS = HTTP + TLSTCP 连接建立之后，在收发 HTTP 数据之前，先执行 TLS 握手，协商一套安全参数。握手完成后，所有 HTTP 请求响应，都会交给 TLS 层做加密、完整性校验，再交给 TCP 传输。 端口：TCP 443。

TLS 所处位置： 应用层 (HTTP) ↔TLS 安全层↔ 传输层 (TCP) ↔ 网络层 IP

HTTP/3 例外：HTTP/3 不再跑 TCP，跑 QUIC，TLS 直接内置在 QUIC 协议内部，不再是独立分层。

TLS 要一次性解决 3 个问题：

1. 保密性：传输的数据不能被中间人窃听看懂
2. 完整性：传输的数据在半路不能被篡改
3. 身份认证：客户端确认自己连接的服务器，不是伪造的中间人

二、两类加密算法（TLS 的基础）

1. 对称加密

特点：加密、解密使用同一个密钥。 代表算法：AES（最常用）、DES（老旧淘汰）。

• 优点：计算速度很快，适合大批量数据加密（网页、聊天消息）
• 缺点：密钥分发难题。双方怎么安全交换这个共同密钥？如果直接在网络传密钥，中间人抓到就可以解密全部通信。

TLS 握手结束后，所有 HTTP 业务流量，全部使用对称加密传输。

2. 非对称加密（公钥密码）

一对密钥：公钥、私钥，数学绑定，成对生成。

• 公钥：可以公开分发，任何人都能拿到
• 私钥：必须严格保密，不能泄露

两种用法，一定要分开：

用法 1：加密（公钥加密，私钥解密）

A 想发秘密消息给 B，A 拿B 的公钥加密消息，发送出去。 只有 B 手里的私钥，才能解开。中间人拿到密文，没有私钥无法解密。 👉 作用：保密，传递秘密信息缺点：运算量巨大，速度极慢，只能加密很短的数据，不能用来加密网页这种大数据。

用法 2：数字签名（私钥签名，公钥验签）

数字签名不是加密原文！ 流程：

1. 原始数据，经过哈希函数（SHA256），生成固定长度哈希摘要。摘要相当于数据的指纹，原文只要改 1 个 bit，摘要完全改变。
2. 发送方用自己私钥加密这个哈希摘要，加密后的结果，就是数字签名。
3. 发送内容 =【原始数据 + 数字签名】
4. 接收方： ① 收到原始数据，自己计算一遍哈希摘要 ② 使用发送方的公钥解密签名，得到发送方算出的原始摘要 ③ 对比两个摘要：相同 = 数据没被篡改，并且确定是持有对应私钥的人发出；不相等 = 数据被改或者签名伪造。

👉 数字签名目标：证明身份 + 校验数据完整性，不做保密任何人都能用公钥验签，只能验证，不能用来加密原文（这和公钥加密是两套独立场景）。

三、数字证书 & CA（证书机构）

问题：公钥从网络拿过来，怎么确认这个公钥真的属于目标网站？

假设中间人劫持你的网络，服务器发给你的公钥被替换成中间人自己的公钥。你以为拿到百度公钥，实际拿到中间人公钥，所有加密内容中间人都能解密。CA 就是解决公钥身份信任问题。

数字证书本质是一个文件，里面包含：

1. 证书对应的域名（如www.baidu.com）
2. 网站的公钥
3. 证书有效期
4. CA 机构信息
5. CA 用自己私钥，对上面所有信息生成的数字签名

证书验证过程

操作系统、浏览器出厂就预装了各大根 CA 的根公钥。 客户端拿到网站证书后：

验证根证书：用根证书里面自带的根 CA 公钥，验证这张根证书自身的签名（自签名）。验证通过，代表我们信任这个公钥。

1. 提取证书里的信息 + CA 的签名
2. 使用内置 CA 根公钥，验证 CA 的数字签名
3. 验签成功 → 确认这份证书内容没有被篡改，证书里的公钥确实属于这个域名
4. 额外校验：证书是否过期；域名和访问地址匹配；证书有没有被吊销。

关键点：CA 的私钥极其重要，一旦泄露，就可以伪造任意网站证书。网站只保存自己的私钥；证书里放的永远是网站公钥。

证书链结构：

根CA（本地预装） → 中间CA证书（服务器下发） → 网站叶子证书（服务器下发）

证书链：很多证书不是根 CA 直接签发，是中间 CA 签发。客户端需要逐级验签，直到根 CA。

TLS证书链验证完整过程

前置条件

1. 客户端本地操作系统 / 浏览器预置可信根 CA 证书（含根 CA 公钥，信任锚点）
2. TLS 握手时，服务端推送中间 CA 证书 + 叶子站点证书（不推送根证书）
3. 证书层级：根 CA → 中间 CA → 叶子站点证书

核心规则

每一级证书由上一级 CA 私钥签名每一级证书由上一级 CA 公钥验签验签本质：本地哈希 (tbsCertificate) == 签名解密后的原始哈希摘要

完整标准验证步骤

1. 验证中间 CA 证书

1. 提取中间证书tbsCertificate（证书待签名主体数据）
2. 客户端根据证书指定哈希算法，本地计算 tbs 哈希摘要 D1
3. 使用本地预置根 CA 公钥，解密 / 校验中间证书的签名值，得到签发时根 CA 生成的原始摘要 D2
4. 比对 D1 == D2，校验签名完整性与合法性
5. 附加合规校验：
   • 证书时间有效性（未过期、已生效）
   • BasicConstraints 为 CA 证书，具备签发下级证书权限
   • 证书未被吊销（CRL/OCSP）

结果：确认中间 CA 公钥合法可信

2. 验证叶子站点证书

1. 提取叶子证书tbsCertificate
2. 客户端本地计算 tbs 哈希摘要 S1
3. 使用已验证合法的中间 CA 公钥，校验叶子证书签名，得到中间 CA 签发时的原始摘要 S2
4. 比对 S1 == S2，确认叶子证书未篡改、为合法 CA 签发
5. 强制附加业务校验（签名通过也必须校验）：
   • 证书有效期合法
   • SAN/CN 域名与访问域名完全匹配
   • ExtendedKeyUsage 包含 ServerAuth（允许网站认证）
   • 证书状态未吊销

结果：确认站点公钥真实可信，归属当前访问域名

最终结论

证书链逐级验签完成，信任传递成立客户端正式信任叶子证书内的服务器公钥，进入 TLS 密钥交换阶段。

四、TLS 握手（TLS1.2 完整流程）

前提：TCP 三次握手完成，TCP 连接已经建立，接下来开始 TLS 握手。

1. ClientHello（客户端 → 服务器）客户端发送：

• 支持的 TLS 版本
• 客户端支持的加密套件列表（AES、哈希算法组合）
• Client Random：客户端生成一段随机数
• SNI：指定要访问的域名（一台服务器托管多个网站，用来选择对应证书）

1. ServerHello（服务器 → 客户端）服务器返回：

• 选定的 TLS 版本
• 选中的加密套件
• Server Random：服务器生成一段随机数
• 服务器证书链（网站证书 + 中间证书）

1. 客户端校验证书浏览器用内置 CA 公钥验证证书签名，检查有效期、域名、吊销状态。校验失败直接终止连接、弹出不安全警告。
2. 密钥交换阶段（两种模式：RSA / ECDHE）

RSA 模式（老，现在很少用，无向前保密） 客户端生成 Pre-Master Secret（预主密钥），用服务器公钥加密发给服务器。服务器用自己私钥解密拿到 Pre-Master Secret。

ECDHE（主流，支持前向保密） 双方交换临时椭圆曲线公钥。客户端拿自己私钥 + 服务器临时公钥算出 Pre-Master Secret；服务器拿自己私钥 + 客户端临时公钥算出 Pre-Master Secret。两边算出完全一样的预主密钥。 ECDHE 的优势：就算网站私钥以后泄露，之前所有历史抓包流量，依然无法解密，这个特性叫前向保密。RSA 不具备。

1. 生成会话密钥 客户端、服务器，三方材料：Client Random + Server Random + Pre-Master Secret，双方各自用相同算法算出一套对称会话密钥（包含加密密钥、校验用密钥）。
2. 两端互相发送 ChangeCipherSpec（切换密码规范） 通知对方：后面报文全部启用对称加密传输。
3. 两端互相发送 Finished 消息 Finished 消息内容，是本次握手全过程所有报文的哈希，使用刚生成的会话密钥加密。 作用：校验整个握手流程没有被中间人篡改。如果中间人修改握手报文，两边哈希对不上，直接断开连接。

✅ TLS 握手结束。之后所有 HTTP 请求、响应，全部使用这套对称会话密钥加密传输。

TLS1.3 改动

简化握手流程，去掉很多不安全加密套件，默认 ECDHE。

• 普通场景：1-RTT（一次往返）完成握手，比 TLS1.2 更快
• 0-RTT：客户端可以在握手阶段直接带上 HTTP 请求，减少一次往返，代价是有一定重放攻击风险，不是所有网站开启。

五、TLS 报文传输特点 & 完整性保护

TLS 不只是加密，每一段 TLS 记录，附带消息认证码 MAC（或者 AEAD 认证加密，现代套件用这个）。 就算中间人把密文随便改一个字节，接收方校验 MAC 会失败，直接丢弃报文，保证数据完整性。

区分：

• 数字签名：证书层面，一次性验证服务器身份，握手阶段使用
• MAC/AEAD：业务传输阶段，每一个数据包做完整性校验

5.1 验证mac过程例子

• 共享密钥：abc123消息：hello发送方：HMAC (key=abc123, msg=hello) → 输出XYZ789发送包：hello + XYZ789

  中间人抓到包，把消息改成helloworld，中间人没有 abc123 密钥，无法算出正确的 MAC。 接收方拿到 helloworld，用 abc123 算 MAC，结果≠XYZ789 → 判断报文被篡改，丢弃。

  注意：中间人可以修改消息 + 随便伪造一个 MAC，但是没有密钥，伪造出来的 MAC 一定无法匹配接收方计算结果。

六、中间人攻击原理，以及 TLS 如何防御

中间人处在客户端和服务器链路中间，可以转发、查看、修改数据包。

1. 无 TLS（纯 HTTP）：中间人直接读取、修改全部明文，毫无阻碍。
2. 如果只有非对称加密，没有 CA 证书：中间人可以替换服务器公钥，客户端无法识别，中间人解密再重新加密转发流量。
3. HTTPS+CA 证书：中间人无法伪造合法证书（没有 CA 私钥）。客户端验签失败，直接拒绝连接，中间人攻击失效。

七、常见概念澄清

1. 对称加密用来传业务数据；非对称 / 数字签名，只用在握手阶段，传递密钥、证明身份，不会加密网页内容。
2. 数字签名 ≠ 加密。签名用来验身份和完整性；加密用来保密。
3. 证书里存网站公钥；网站服务器本地保存网站私钥。CA 证书签名是 CA 用 CA 私钥签的。
4. TLS 跑在 TCP 之上，所以 TCP 的问题（队头阻塞）TLS 解决不了，这也是 QUIC+HTTP3 出现的原因。、