# 需求:NAS-MySQL-开发库改用公司-CA-签发带-IP-SAN-的服务端证书

状态: proposed
归属: 公司运营
来源: boss 直投(会话)
日期: 2026-10-20
建议: 做,卡面主线是装根证书、别关 TLS 校验,开发库自签证书是唯一真空带;公司 CA 现成,签一张即可对齐

## 现状

- 2026-10-20 员工第四轮实测(N12):开发库 `192.168.31.192:3306`(`1Panel-mysql-JnwF`)用的是 MySQL 8.4.9 自签证书 ——
  `subject=CN=MySQL_Server_8.4.9_Auto_Generated_Server_Certificate`、`issuer=CN=MySQL_Server_8.4.9_Auto_Generated_CA_Certificate`,**没有 SAN**;
  `openssl verify -CAfile ca.crt` → `error 20: unable to get local issuer certificate`;`require_secure_transport = 0`。
- 加密是有的(实测协商 `ECDHE-RSA-CHACHA20-POLY1305 / TLSv1.2`),但身份没人认:客户端默认不校验,所以大家「连得上」。
  卡面主线却是「先装根证书、别关 TLS 校验」——照这个原则给 MySQL 开 `--ssl-verify-server-cert` / `VERIFY_CA` 的人必然报
  `self signed certificate in certificate chain`,属于卡面原则与实况的唯一真空带。
- 这枚 Auto_Generated 证书每次重建实例都会重新生成,无法固定成可校验的身份。
- 对照:Gitea 的 `CN=192.168.31.192` 证书就是公司 CA 签的,验签 `return code: 0` —— 内部 CA 完全够用,不是能力问题。
- 卡面已先做诚实口径(2026-10-20):明确写「开发库暂不校验服务端证书,别照搬第 1 步」。那张 81 字的说明是临时兜底,
  本票完成后应改回「装好根证书即可开校验」。

## 方案

1. 用公司 CA(`/opt/onboard-hub/secrets/ca/`,与 onboard-hub / Gitea 同一套)给 MySQL 签一张服务端证书:
   **SAN 必须含 `IP:192.168.31.192`**(客户端是按 IP 连的,没有 SAN 的 CN 匹配在现代客户端已不被接受)。
2. 把 `server.crt`/`server.key` 只读挂进 `1Panel-mysql-JnwF`,在 MySQL 配置里指 `ssl_cert` / `ssl_key`
   (key 权限 0600、属主 999/mysql);证书由文件挂载持有,实例重建不再自动生成。
3. 重启该容器使新证书生效 —— 这是**共享库**(`onboard_hub` 与 `gitea_efhj4k` 两个 schema 都在这台上),
   重启窗口需 boss 拍板,不与发版/开通链同时段。
4. 验证通过后再把 `require_secure_transport` 打开(可选,属于加固第二步),并同步改卡面口径。

## 验收标准

- [ ] `openssl s_client -connect 192.168.31.192:3306 -starttls mysql -CAfile ~/.pinnadash/ca.crt` 的 `Verify return code: 0 (ok)`
- [ ] 证书 `issuer` 为公司 CA、SAN 含 `IP:192.168.31.192`;容器重建后指纹不变
- [ ] `mysql --ssl-verify-server-cert` 用开发库账号能连上(口令取自卡面/凭据仓,不进命令行)
- [ ] 卡面「开发库暂不校验服务端证书」的临时说明改为「装好根证书即可开校验」,并有线上探针断言
- [ ] 共享库重启前后 `onboard_hub` 与 `gitea_efhj4k` 各做一次连通性冒烟(开通链 + Git 智能协议)