HTTPS 是怎么工作的？Tomcat 怎么配置 HTTPS/SSL？

简化版

**HTTPS = HTTP + TLS/SSL 加密——在 HTTP 之下加一层 TLS，让传输的数据「加密（防窃听）+ 完整性校验（防篡改）+ 身份认证（防冒充，靠证书）」。**核心流程（TLS 握手）：① 客户端发起握手，服务端返回「证书」（含服务端公钥、由 CA 签名）；② 客户端验证证书（是不是可信 CA 签的、域名对不对、没过期）；③ 双方通过「非对称加密」协商出一个「对称密钥」（会话密钥）；④ 之后用这个对称密钥加密通信（对称加密快）。所以 HTTPS 是「非对称加密协商密钥 + 对称加密传数据」的混合——既安全又高效。Tomcat 配置 HTTPS：在 server.xml 里配一个「支持 SSL 的 Connector」，指定「证书（keystore/PEM）+ 密码 + 端口（443）+ TLS 协议版本」。证书的来源：生产用 CA 签发的证书（如 Let’s Encrypt 免费、或付费证书）；开发/测试可以自签名证书（keytool 生成，但浏览器会警告不可信）。Spring Boot 更简单：server.ssl.* 配置（证书路径、密码），一行搞定。核心：HTTPS 用 TLS 加密（非对称协商密钥+对称传数据），靠证书认证身份；Tomcat 配 SSL Connector（证书+密码+端口）。

详细版

HTTP vs HTTPS：

维度	HTTP	HTTPS
加密	明文（可被窃听）	TLS 加密（防窃听）
完整性	无（可被篡改）	有（防篡改）
身份认证	无（可被冒充）	有（证书，防冒充）
端口	80	443
性能	快	稍慢（握手+加密开销）

<!-- Tomcat server.xml 配置 HTTPS Connector -->
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="200" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/keystore.jks"
                     certificateKeystorePassword="password"
                     type="RSA" />
        <!-- 或用 PEM 证书 -->
        <!-- <Certificate certificateFile="cert.pem"
                          certificateKeyFile="key.pem" /> -->
    </SSLHostConfig>
</Connector>

# Spring Boot 配置 HTTPS（application.properties）
server.port=443
server.ssl.enabled=true
server.ssl.key-store=classpath:keystore.jks
server.ssl.key-store-password=password
server.ssl.key-store-type=JKS
server.ssl.key-alias=tomcat
# 强制 HTTP 跳转 HTTPS 要额外配（或用网关/Nginx 处理）

⚠️ HTTPS 的核心是「混合加密 + 证书信任」，理解这两点就理解了 HTTPS。混合加密：为什么不全用对称加密（快）或全用非对称加密（安全）？因为对称加密快但「密钥怎么安全地传给对方」是难题（明文传密钥等于没加密）、非对称加密安全（公钥加密私钥解密，公钥可公开）但慢。HTTPS 巧妙结合：用非对称加密「安全地协商出一个对称密钥」（解决密钥分发），之后用对称密钥加密通信（解决性能）——两全其美。证书信任：光加密还不够，还要确认「对方是不是真的是它声称的那个服务器」（防中间人冒充）——靠证书：服务端的证书由受信任的 CA（证书颁发机构）签名，客户端（浏览器）内置了信任的 CA 列表，验证证书是不是可信 CA 签的、域名对不对、没过期，验证通过才信任。中间人攻击就是攻击者冒充服务端，但它拿不到可信 CA 对目标域名的签名，所以证书验证会失败。生产环境一定要用可信 CA 的证书（自签名证书浏览器会警告），Let’s Encrypt 提供免费证书。

完整版教学

一、HTTPS 解决什么

先理解 HTTP 的问题和 HTTPS 解决什么：

HTTP 的问题（明文传输）：
  ① 可被窃听——数据明文传，中间人（路由器、WiFi、运营商）能看到
     → 密码、隐私、支付信息暴露
  ② 可被篡改——中间人能修改传输的数据
     → 页面被插广告、被篡改
  ③ 可被冒充——无法确认"对方是不是真的目标服务器"
     → 钓鱼、中间人攻击

HTTPS 解决（三个安全保证）：
  ① 加密（Confidentiality）——数据加密传输，防窃听
  ② 完整性（Integrity）——校验数据没被篡改
  ③ 身份认证（Authentication）——靠证书确认对方身份，防冒充

HTTPS = HTTP + TLS/SSL：
  在 HTTP 之下加一层 TLS（Transport Layer Security）
  → HTTP 应用层不变，TLS 负责加密和认证
  → 上层还是 HTTP，只是数据经过 TLS 加密

TLS vs SSL：
  SSL 是老的（已废弃，有漏洞）
  TLS 是新的（TLS 1.2、1.3，现在用 TLS）
  → 习惯上还叫 SSL，实际用 TLS

所以 HTTPS = HTTP + TLS，提供加密、完整性、身份认证

HTTP 的问题（明文传输）——① 可被窃听（中间人能看到明文，密码隐私暴露）、② 可被篡改（中间人改数据，插广告）、③ 可被冒充（无法确认对方是不是真服务器，钓鱼/中间人攻击）。HTTPS 解决（三个安全保证）：① 加密（防窃听）、② 完整性（防篡改）、③ 身份认证（靠证书确认身份，防冒充）。HTTPS = HTTP + TLS/SSL（HTTP 之下加一层 TLS 负责加密认证、上层还是 HTTP）。TLS 是新的（SSL 已废弃有漏洞、现在用 TLS 1.2/1.3）。理解「HTTP 问题:可窃听/可篡改/可冒充;HTTPS 解决:加密(防窃听)+完整性(防篡改)+身份认证(证书防冒充);HTTPS=HTTP+TLS;TLS 新 SSL 废弃」，就理解了 HTTPS 解决什么。

二、混合加密：非对称+对称

理解 HTTPS 的「混合加密」——核心机制：

两种加密方式：
  对称加密（AES 等）：
    加密解密用同一个密钥
    优点：快（性能好）
    缺点：★密钥分发难——怎么把密钥安全地给对方？
      （明文传密钥 = 被截获 = 没加密）
  非对称加密（RSA 等）：
    一对密钥：公钥（可公开）+ 私钥（保密）
    公钥加密的只有私钥能解（反之亦然）
    优点：安全（公钥可公开，不怕被知道）
    缺点：慢（计算复杂）

HTTPS 的混合加密（巧妙结合）：
  ① 用非对称加密"协商"出一个对称密钥（会话密钥）：
     - 服务端有公钥/私钥，公钥在证书里给客户端
     - 客户端生成对称密钥，用服务端公钥加密后发给服务端
     - 只有服务端私钥能解 → 双方都有了对称密钥（安全协商）
     → 解决了"密钥分发难"（用非对称传对称密钥）
  ② 之后用对称密钥加密通信：
     - 双方用协商好的对称密钥加解密数据
     → 快（对称加密性能好）

  （TLS 1.3 用更安全的密钥交换如 ECDHE，原理类似——安全协商对称密钥）

为什么混合：
  非对称安全但慢 → 只用它协商密钥（少量）
  对称快但密钥分发难 → 用非对称解决分发后，用它传大量数据
  → 两全其美：安全 + 高效

所以 HTTPS = 非对称协商对称密钥 + 对称加密传数据（混合加密）

HTTPS 的混合加密（核心机制）——两种加密：对称加密（AES，加解密同一密钥，快但密钥分发难，明文传密钥等于没加密）、非对称加密（RSA，公钥+私钥，公钥加密私钥解，安全但慢）。HTTPS 巧妙结合：① 用非对称加密协商出对称密钥（服务端公钥在证书里、客户端生成对称密钥用公钥加密发给服务端、只有私钥能解、双方都有了对称密钥、解决密钥分发难）；② 之后用对称密钥加密通信（快）。为什么混合：非对称安全但慢只用它协商密钥、对称快用它传大量数据、两全其美。理解「HTTPS 混合加密:对称加密(快但密钥分发难)+非对称加密(安全但慢);①非对称协商对称密钥(公钥在证书、客户端生成对称密钥用公钥加密只有私钥能解、解决密钥分发)②对称密钥传数据(快);两全其美安全+高效」，就掌握了混合加密。

三、证书与身份认证

理解「证书」——身份认证，防中间人：

光加密还不够——要确认"对方是不是真的目标服务器"（防冒充）：
  中间人攻击：攻击者冒充服务端
  → 你以为在和银行通信，其实在和攻击者通信

证书（Certificate）解决身份认证：
  服务端有一个"数字证书"，含：
    - 服务端的公钥
    - 服务端的身份信息（域名等）
    - CA（证书颁发机构）的签名

CA（Certificate Authority）：
  受信任的第三方机构，给服务端的证书"签名"担保
  → CA 用自己的私钥签名，证明"这个证书是可信的"
  浏览器/操作系统内置了信任的 CA 列表（根证书）

验证证书（客户端做）：
  ① 证书是不是可信 CA 签的（用 CA 公钥验签，CA 公钥在浏览器里）
  ② 域名对不对（证书的域名 = 你访问的域名）
  ③ 没过期
  → 都通过 → 信任这个服务端（真的是它声称的）
  → 有问题 → 浏览器警告（不安全）

为什么中间人攻击失败：
  攻击者冒充银行，但拿不到"可信 CA 对银行域名的签名"
  → 它的证书验证会失败（域名不对/不是可信 CA 签的）
  → 浏览器警告 → 攻击被发现

证书类型/来源：
  可信 CA 签发（生产用）：Let's Encrypt（免费）、付费证书
  自签名（开发用）：keytool 生成，浏览器会警告（不可信）

所以证书 = CA 签名的身份凭证，客户端验证确认服务端身份（防中间人）

证书（身份认证，防中间人）——光加密不够，要确认对方是不是真服务器（中间人攻击是攻击者冒充服务端）。证书含服务端公钥+身份信息（域名）+CA 签名。CA（证书颁发机构） 是受信任的第三方，用私钥给证书签名担保（浏览器内置信任的 CA 列表）。验证证书：① 是不是可信 CA 签的（用 CA 公钥验签）、② 域名对不对、③ 没过期——都通过才信任。中间人攻击失败：攻击者拿不到可信 CA 对目标域名的签名、证书验证失败。证书来源：可信 CA（生产，Let’s Encrypt 免费/付费）、自签名（开发，浏览器警告不可信）。理解「证书身份认证:含服务端公钥+域名+CA 签名;CA 受信任第三方签名担保(浏览器内置信任列表);验证:可信 CA 签的+域名对+没过期;中间人攻击失败(拿不到可信 CA 签名);生产用可信 CA(Let’s Encrypt 免费)、开发自签名(警告)」，就掌握了证书与身份认证。

四、TLS 握手流程

把 TLS 握手流程串起来：

TLS 握手（简化，建立 HTTPS 连接）：
  1. 客户端 → ClientHello：
     发起握手，告诉服务端支持的 TLS 版本、加密套件、随机数

  2. 服务端 → ServerHello + 证书：
     选定 TLS 版本、加密套件、随机数
     发送服务端的证书（含公钥）

  3. 客户端验证证书：
     - 验证证书（可信 CA 签的、域名对、没过期）
     - 通过 → 继续；不通过 → 警告/中断

  4. 密钥协商（用非对称）：
     客户端生成"预主密钥"，用服务端公钥加密后发给服务端
     只有服务端私钥能解 → 双方基于随机数 + 预主密钥算出"会话密钥"（对称）
     （TLS 1.3 用 ECDHE，更安全、握手更快）

  5. 握手完成：
     双方都有会话密钥（对称）
     之后用会话密钥加密通信（对称加密）

  → 握手用非对称（协商密钥）、之后用对称（传数据）

TLS 1.3 的改进：
  ① 握手更快（1-RTT，甚至 0-RTT）
  ② 更安全（去掉不安全的算法）
  → 现在优先用 TLS 1.3

握手的开销：
  HTTPS 比 HTTP 慢一点（握手 + 加密开销）
  但 TLS 1.3 优化后，开销可接受（且可复用会话）

所以 TLS 握手 = 协商版本/套件 → 验证证书 → 协商对称密钥 → 加密通信

TLS 握手流程：1. 客户端 ClientHello（支持的 TLS 版本/加密套件/随机数）→ 2. 服务端 ServerHello + 证书（选定版本套件、发证书含公钥）→ 3. 客户端验证证书（可信 CA/域名/没过期）→ 4. 密钥协商（客户端生成预主密钥用服务端公钥加密、只有私钥能解、双方算出会话密钥对称；TLS 1.3 用 ECDHE）→ 5. 握手完成用会话密钥加密通信。握手用非对称（协商密钥）、之后用对称（传数据）。TLS 1.3 改进：握手更快（1-RTT/0-RTT）、更安全。理解「TLS 握手:ClientHello→ServerHello+证书→客户端验证证书→密钥协商(预主密钥用公钥加密算出会话密钥)→加密通信;握手非对称+之后对称;TLS 1.3 握手更快更安全」，就掌握了 TLS 握手。

五、Tomcat 配置 HTTPS

理解 Tomcat 怎么配 HTTPS：

Tomcat 配 HTTPS（server.xml 的 SSL Connector）：
  <Connector port="443" protocol="Http11NioProtocol" SSLEnabled="true">
    <SSLHostConfig>
      <Certificate certificateKeystoreFile="conf/keystore.jks"
                   certificateKeystorePassword="password" type="RSA" />
    </SSLHostConfig>
  </Connector>

关键配置：
  ① port="443"：HTTPS 默认端口
  ② SSLEnabled="true"：启用 SSL
  ③ 证书：
     - keystore（JKS/PKCS12 格式）：certificateKeystoreFile + password
     - 或 PEM 证书：certificateFile + certificateKeyFile
  ④ 协议版本：可指定 TLS 1.2/1.3（sslProtocol/sslEnabledProtocols）

证书格式：
  JKS（Java KeyStore）：Java 传统格式，keytool 生成
  PKCS12（.p12/.pfx）：标准格式，跨平台
  PEM（.pem/.crt + .key）：常见的证书格式（CA 签发的常是这个）

生成/获取证书：
  自签名（开发）：keytool -genkeypair -keystore keystore.jks ...
  CA 签发（生产）：从 CA 拿证书（Let's Encrypt、付费）

Spring Boot 配置（更简单）：
  server.ssl.key-store=classpath:keystore.jks
  server.ssl.key-store-password=password
  server.port=443
  → 一行配置，内嵌 Tomcat 自动启用 HTTPS

HTTP 跳 HTTPS：
  强制把 HTTP 请求跳转到 HTTPS
  → Tomcat 配 security-constraint，或用 Nginx/网关处理

所以 Tomcat 配 HTTPS = SSL Connector（端口443+证书+密码+TLS 版本）

Tomcat 配 HTTPS（server.xml 的 SSL Connector）：port="443"、SSLEnabled="true"、证书（keystore JKS/PKCS12 或 PEM）、TLS 协议版本。证书格式：JKS（Java 传统，keytool 生成）、PKCS12（标准跨平台）、PEM（CA 签发常是这个）。生成/获取：自签名（开发，keytool）、CA 签发（生产，Let’s Encrypt/付费）。Spring Boot 更简单（server.ssl.key-store+password+server.port=443、内嵌 Tomcat 自动启用）。HTTP 跳 HTTPS 用 security-constraint 或 Nginx/网关。理解「Tomcat 配 HTTPS:SSL Connector(port 443+SSLEnabled+证书 keystore/PEM+TLS 版本);证书格式 JKS/PKCS12/PEM;自签名开发 keytool、CA 签发生产;Spring Boot server.ssl.*一行配置;HTTP 跳 HTTPS 用 security-constraint 或 Nginx」，就掌握了 Tomcat 配 HTTPS。

六、实践与总结

总结 HTTPS 的实践：

实践建议：
  ① 生产一定用 HTTPS（保护数据、SEO、浏览器要求）
  ② 用可信 CA 的证书（Let's Encrypt 免费、或付费）
     → 别用自签名（浏览器警告、用户不信任）
  ③ 用 TLS 1.2/1.3（禁用不安全的 SSL/老 TLS）
  ④ HTTP 强制跳 HTTPS（HSTS 头、或跳转）
  ⑤ 证书要及时续期（Let's Encrypt 90 天，要自动续）

架构考量（HTTPS 在哪终止）：
  ① Tomcat 直接终止 HTTPS（配 SSL Connector）
     → 应用直接处理 HTTPS
  ② 在 Nginx/负载均衡/网关终止 HTTPS（SSL 卸载）
     → 负载均衡处理 HTTPS，到后端 Tomcat 用 HTTP（内网）
     → 常见做法：SSL 卸载（offload），减轻后端负担
     → 后端用 RemoteIpValve 拿真实 IP、判断是否 HTTPS（X-Forwarded-Proto）

性能：
  HTTPS 有握手 + 加密开销（比 HTTP 慢一点）
  但 TLS 1.3 优化、会话复用、HTTP/2 后，开销可接受
  → 现代都用 HTTPS（安全 > 一点性能）

核心总结：
  HTTPS = HTTP + TLS（加密+完整性+身份认证）
  混合加密：非对称协商对称密钥 + 对称传数据
  证书：CA 签名的身份凭证，验证防中间人
  Tomcat 配 SSL Connector（证书+密码+端口443）
  生产用可信 CA 证书 + TLS 1.2/1.3，常在网关/Nginx 做 SSL 卸载

HTTPS 实践：① 生产一定用 HTTPS、② 用可信 CA 证书（Let’s Encrypt 免费，别用自签名）、③ 用 TLS 1.2/1.3、④ HTTP 强制跳 HTTPS（HSTS）、⑤ 证书及时续期。架构考量（HTTPS 在哪终止）：Tomcat 直接终止（配 SSL Connector）或在 Nginx/网关终止（SSL 卸载、后端用 HTTP、常见做法，后端用 RemoteIpValve 拿真实 IP 和 X-Forwarded-Proto 判断 HTTPS）。性能：HTTPS 有开销但 TLS 1.3/会话复用/HTTP/2 后可接受。理解「实践:生产用 HTTPS+可信 CA 证书+TLS 1.2/1.3+HTTP 跳 HTTPS+证书续期;架构:Tomcat 直接终止或 Nginx/网关 SSL 卸载(后端 HTTP、RemoteIpValve+X-Forwarded-Proto);性能可接受」，就掌握了 HTTPS 的实践。

记忆钩子：「HTTPS=HTTP+TLS/SSL(加密防窃听+完整性防篡改+身份认证防冒充,端口443);★混合加密:对称加密(AES 快但密钥分发难)+非对称加密(RSA 安全但慢),①非对称协商对称密钥(服务端公钥在证书、客户端生成对称密钥用公钥加密只有私钥能解、解决密钥分发)②对称密钥传数据(快),两全其美;★证书:含服务端公钥+域名+CA 签名,CA 受信任第三方(浏览器内置信任列表),验证(可信 CA 签+域名对+没过期)防中间人;TLS 握手:ClientHello→ServerHello+证书→验证证书→协商会话密钥→加密通信,TLS 1.3 更快更安全;Tomcat 配 SSL Connector(port 443+证书 keystore/PEM+密码+TLS 版本),Spring Boot server.ssl.*;生产用可信 CA(Let’s Encrypt 免费)、常在 Nginx/网关 SSL 卸载」。

七、常见误区与追问

• 误区：HTTPS 全程用非对称加密。 不是——HTTPS 是混合加密：握手阶段用非对称加密协商出一个对称密钥（解决密钥分发难题），之后的数据传输用对称加密（性能好）；因为非对称加密慢，只用它协商密钥（少量），对称加密快用它传大量数据，两全其美。
• 误区：只要加密就安全了，不用证书。 光加密不够——还要确认「对方是不是真的目标服务器」（防中间人冒充）；靠证书：服务端证书由受信任的 CA 签名，客户端验证证书（可信 CA 签的、域名对、没过期）确认服务端身份；没有证书验证，中间人可以冒充服务端、加密也白搭。
• 误区：自签名证书和 CA 签发的证书一样安全。 自签名证书没有可信 CA 的背书——浏览器/操作系统不信任它（会警告「不安全」「证书无效」），因为无法确认签发者可信；生产环境一定要用可信 CA 签发的证书（Let’s Encrypt 免费、或付费），自签名只适合开发/测试。
• 误区：配了 HTTPS 后 HTTP 就自动禁用了。 不会——HTTP（80）和 HTTPS（443）是不同端口，配了 HTTPS 后 HTTP 可能还能访问；要强制用 HTTPS 需要额外配置：把 HTTP 请求跳转到 HTTPS（重定向）、或用 HSTS 头（告诉浏览器以后只用 HTTPS）；否则用户还能通过 HTTP 明文访问。
• 追问：HTTPS 是怎么保证安全的？ 三方面：① 加密——数据用 TLS 加密传输，中间人窃听只能看到密文（防窃听）；② 完整性——有校验机制，数据被篡改能发现（防篡改）；③ 身份认证——服务端证书由受信任的 CA 签名，客户端验证证书确认服务端身份（防冒充/中间人攻击）；加密用混合加密（非对称协商对称密钥 + 对称传数据，既安全又高效）；证书验证用 CA 信任链（浏览器内置信任的 CA，验证证书是可信 CA 签的、域名对、没过期）。
• 追问：为什么 HTTPS 要用「非对称+对称」混合加密？ 因为两种加密各有优劣：对称加密快（性能好）但密钥分发难（怎么把密钥安全地给对方？明文传密钥等于没加密）；非对称加密安全（公钥可公开，公钥加密私钥解密）但慢（计算复杂）；HTTPS 结合两者：用非对称加密安全地协商出一个对称密钥（服务端公钥在证书里，客户端用它加密对称密钥发给服务端，只有服务端私钥能解），解决了密钥分发难题，之后用这个对称密钥加密通信，解决了性能问题；这样既安全又高效。
• 追问：Tomcat 怎么配置 HTTPS？生产上 HTTPS 一般在哪里终止？ Tomcat 配置：在 server.xml 里配一个 SSLEnabled 的 Connector（端口 443），指定证书（keystore JKS/PKCS12 或 PEM 格式）、证书密码、TLS 协议版本；Spring Boot 更简单，用 server.ssl.key-store、server.ssl.key-store-password、server.port=443 配置。生产上 HTTPS 通常在 Nginx、负载均衡器或 API 网关终止（SSL 卸载/offload）——它们处理 HTTPS 加解密，到后端 Tomcat 用 HTTP（内网明文，减轻后端负担）；这种情况后端要用 RemoteIpValve 拿真实客户端 IP、用 X-Forwarded-Proto 头判断原始请求是不是 HTTPS。

八、加强记忆

HTTPS = HTTP + TLS/SSL 加密——在 HTTP 之下加一层 TLS，提供「加密（防窃听）+ 完整性（防篡改）+ 身份认证（靠证书防冒充）」，端口 443（TLS 是新的，SSL 已废弃）。核心是混合加密 + 证书信任：① 混合加密——对称加密（AES）快但密钥分发难、非对称加密（RSA）安全但慢；HTTPS 用非对称加密安全地协商出一个对称密钥（解决密钥分发），之后用对称密钥加密通信（解决性能），两全其美；② 证书信任——服务端证书含公钥+域名+CA 签名，客户端验证证书（可信 CA 签的、域名对、没过期）确认服务端身份，防中间人（攻击者拿不到可信 CA 对目标域名的签名）。TLS 握手：ClientHello → ServerHello+证书 → 客户端验证证书 → 协商会话密钥（对称）→ 加密通信（TLS 1.3 更快更安全）。Tomcat 配 HTTPS：server.xml 配 SSL Connector（port=443、SSLEnabled=true、证书 keystore/PEM、密码、TLS 版本）；Spring Boot 用 server.ssl.*。生产用可信 CA 证书（Let’s Encrypt 免费，别用自签名），用 TLS 1.2/1.3，常在 Nginx/网关做 SSL 卸载（后端用 HTTP + RemoteIpValve + X-Forwarded-Proto）。一句话「HTTPS=HTTP+TLS(加密+完整性+身份认证,端口443);混合加密:非对称协商对称密钥(解决密钥分发)+对称传数据(快);证书 CA 签名验证防中间人;TLS 握手协商密钥再加密通信;Tomcat 配 SSL Connector(证书+密码+443),生产用可信 CA+TLS 1.2/1.3,常在网关 SSL 卸载」。