[Feature] Self-signed certificates are issued without the Subject Alternative Name (SAN) extension, causing TLS verification failures in Go-based applications.

[Cikaros]

1Panel Version

v2.2.5

Please describe your needs or suggestions for improvements

1Panel 面板签发自签证书时，仅填写了证书 CN(Common Name) 字段，没有写入 Subject Alternative Name (SAN) 扩展。

现代 Go 语言标准库 crypto/x509 不再兼容仅依靠 CN 做域名匹配的证书。即使将根 CA 导入系统信任列表，Go 编写的程序（Git‑LFS、Gitea、Docker、curl、各类 go 服务）依然会抛出证书不合规报错：

tls: failed to verify certificate: x509: "gitea.cikaros.local" certificate is not standards compliant

浏览器（Chrome/Firefox）可以兼容仅 CN 的证书，不会阻断访问；但是大量后端、DevOps 工具链（Git‑LFS、容器、内网服务）基于 Go，直接拒绝连接，内网自签环境下可用性很差。

复现步骤

1. 进入 1Panel → 证书 → 使用内置 CA 签发自签证书，填写域名 demo.cikaros.local / 通配符 *.cikaros.local
2. 将证书部署到 Web 服务
3. 使用 Go 编写客户端访问该 HTTPS 服务
4. 触发 TLS x509 校验失败报错

校验证书确认无 SAN 扩展命令：

openssl x509 -in xxx.crt -noout -text

输出中不存在 Subject Alternative Name 段落。

当前现象：证书已经导入系统根信任，浏览器访问完全正常，但是 Go 程序全部 TLS 校验失败。单纯导入 CA 信任无法绕过，必须签发证书时内置 SAN 扩展。

Please describe the solution you suggest

1. 签发自签证书时，自动将填写的域名、通配符域名、IP 写入 SAN (Subject Alternative Name) 扩展字段，CN 同时保留。
2. UI 层面支持手动补充多个域名 / IP 到 SAN 列表，支持 DNS、IP 类型。
3. 通配符域名（*.xxx.xxx）也必须加入 SAN 扩展，仅写 CN 无效。

RFC5280 规范，HTTPS 证书域名校验优先读取 SAN，CN 字段已经废弃，不应作为唯一域名凭证。

Additional Information

• 操作系统：Linux
• 1Panel 版本：v2.2.5
• 受影响场景：内网私有环境、自签证书、Go 语言开发工具链 (Gitea、Git‑LFS 等)

[zhengkunwang223]

好的 我们看一下

[Cikaros]

在Mac中还发现一个问题：缺少 critical 关键字。

RFC‑5280 规定：BasicConstraints 对于 CA 证书必须标记为 critical（关键扩展）。
OpenSSL 宽松：不带 critical 也能正常当作 CA 使用；
Apple SecTrust 强制执行 RFC：根 CA 证书，BasicConstraints 不标记 critical → 直接判定证书链非法，即便你把 CA 导入系统钥匙串并标记为「始终信任」，SecTrust 依然拒绝这条证书链。