生成带 SAN 的自签名证书（兼容新版 Chrome）
现代浏览器证书名称验证依赖 SAN；OpenSSL 可生成带 SAN 的开发用自签证书。SAN 不代表证书已受信，应在受控环境配置可信 CA，保护私钥。
一句话回答：Chrome 58 开始证书必须有 SAN（Subject Alternative Name）扩展，只填 Common Name 的证书会被拒绝（ERR_CERT_COMMON_NAME_INVALID）。openssl 一条命令加 -addext "subjectAltName=DNS:你的域名" 即可；或用 openssl 配置文件批量列 SAN。生成后 openssl x509 -text 确认有 SAN 段。
方法一：-addext 一条命令（OpenSSL 1.1.1+）
umask 077
openssl req -x509 -newkey rsa:2048 -nodes -days 365 -keyout server.key -out server.crt -subj "/CN=dev.test" -addext "subjectAltName=DNS:dev.test,DNS:*.dev.test,IP:127.0.0.1"
方法二：配置文件（SAN 多的时候）
新建 san.cnf：
[req]
prompt = no
distinguished_name = dn
req_extensions = ext
x509_extensions = ext
[dn]
CN = dev.test
[ext]
subjectAltName = DNS:dev.test,DNS:*.dev.test,IP:127.0.0.1
生成：
openssl req -x509 -newkey rsa:2048 -nodes -days 365 -keyout server.key -out server.crt -config san.cnf
验证 SAN 已写入
openssl x509 -in server.crt -text -noout | grep -A1 "Subject Alternative Name"
# X509v3 Subject Alternative Name:
# DNS:dev.test, DNS:*.dev.test, IP:127.0.0.1
证书示例仅限隔离的开发环境。-nodes 会生成无口令私钥，应设 600 权限，不提交到仓库。域名还需解析到测试服务器；使用保留的 .test 避免与 .local 的 mDNS 语义冲突。
浏览器信任
SAN 正确不代表浏览器自动信任。仅在受控测试设备上核对自己生成证书的指纹后，再按客户端信任策略导入；不能让访客安装未知根。下面是常见系统入口，实际组织策略可能限制：
- Windows：双击 crt → 安装证书 → 本地计算机 → 受信任的根证书颁发机构
- macOS：钥匙串访问 → 导入 → 双击设为"始终信任"
本地开发多站点建议直接用 mkcert，自动处理 CA 与 SAN，省去手工流程。
常见问题（FAQ）
Q：证书明明有 CN=dev.test，Chrome 还说域名不匹配？
A：Chrome 自 58 版起完全忽略 CN，只看 SAN。证书没 SAN 段就一定报错，这是本文要解决的问题本身。
Q：IP 地址访问也要加 SAN 吗？
A：要。IP 形式访问时 SAN 里必须写 IP:127.0.0.1 这样的 IP 条目，写 DNS 条目不匹配。
Q：老系统 OpenSSL 没有 -addext 参数？
A：配置文件法可避免依赖 -addext，但不应继续使用已停止安全维护的 OpenSSL。优先升级到系统支持版本，并用 openssl version 确认实际执行程序。
参考资料
本文依据官方资料核对，未进行现场运行测试；代码与配置示例需结合实际版本、权限和环境验证。
