SSCG：让自签名证书不再“危险”的生成工具

在计算机网络安全领域，自签名证书往往被视为一种“必要之恶”——它方便快捷，却因为信任链的缺失而让客户端暴露在中间人攻击的风险之下。SSCG（Simple Signed Certificate Generator）正是为了解决这一矛盾而诞生的工具。它并非简单地生成一张自签名证书，而是通过一种巧妙的设计，让用户在不搭建完整 PKI 环境的前提下，获得安全性接近私有 CA 签发的证书。

核心理念：告别“裸奔”的自签名

传统自签名证书的痛点在于：客户端必须无条件信任这张证书，而这张证书本身没有任何上层信任锚点。如果攻击者伪造了一张同样声称是“server.example.com”的证书，客户端无法区分真伪。

SSCG 的思路不同。它实际上创建了一个临时的私有 CA：首先生成一个 CA 根证书，然后用这个 CA 的私钥去签发服务端证书。最终交付给用户的是一组文件——ca.crt（CA 公钥证书）、service.pem（服务端证书）和 service-key.pem（服务端私钥）。

关键在于，SSCG 默认会在生成后立即销毁 CA 的私钥。这意味着这个 CA 无法再签发任何其他证书，从而从根本上杜绝了 CA 私钥泄露后被滥用的风险。用户只需将 ca.crt 安全地导入客户端信任库，即可让客户端信任由该 CA 签发的服务端证书，安全性远超直接信任一张自签名证书。

功能演进：从 RSA 到后量子密码学

SSCG 并非一个停滞不前的工具。从版本迭代来看，它在密码学支持上持续跟进现代需求：

传统 RSA 支持是基础。早期版本默认使用 2048 位 RSA 密钥，后续版本将私有 CA 的最小 RSA 强度提升至 4096 位，以满足更严格的安全要求。

ECDSA 椭圆曲线支持在 4.0.0 版本引入。相比 RSA，ECDSA 在同等安全强度下密钥更短、性能更好，适合资源受限的场景。用户可以通过 --key-type=ecdsa 配合 --ec-curve 指定曲线（如 secp256r1、secp384r1 等）。

ML-DSA 后量子支持是 4.0.0 版本最具前瞻性的更新。ML-DSA（Module-Lattice-Based Digital Signature Algorithm）是美国 NIST 后量子密码学标准化进程中的成果，旨在抵御未来量子计算机对传统公钥密码体系的威胁。SSCG 通过 OpenSSL 3.5+ 提供这一能力，使用户可以提前布局“抗量子”的证书体系。

设计哲学：简单但不简陋

SSCG 的“Simple”体现在使用方式上，而非功能深度上。

最简单的用法只需在终端执行 sscg 一条命令，它便会以当前系统的主机名为 FQDN，在当前目录生成三个文件，证书有效期默认 398 天，满足主流浏览器对证书寿命的限制要求。

对于更复杂的场景，SSCG 提供了丰富的命令行参数：

主题信息定制：国家、省份、城市、组织、部门、邮箱等 DN 字段均可指定。
备用名称（SAN）：通过 --subject-alt-name 可多次指定额外的域名或 IP 地址，支持多宿主服务器场景。
文件路径与权限：CA 证书、服务证书、各类私钥的存储路径和文件模式（如 0600）都可独立配置。CA 私钥若未指定路径，将被销毁而非写入磁盘。
密钥保护：支持通过密码文件或交互式提示为私钥加密，避免在命令行中明文传递密码。

实战操作：从基础到进阶

基础操作：三步走

场景一：最简单的生成

假设你要为当前机器（主机名为 dev.example.org）生成一张证书。直接在终端运行：

sscg

执行后，当前目录会出现三个文件：

ca.crt：CA 公钥证书，这是唯一需要导入客户端信任库的文件
service.pem：服务端公钥证书
service-key.pem：服务端私钥

关键设计：CA 的私钥默认会被销毁，不会写入磁盘。这意味着即使攻击者拿到了 ca.crt，也无法用它签发新的证书来伪造你的服务。

场景二：指定主机名和多域名

默认情况下，SSCG 使用当前系统的 FQDN 作为证书的 Common Name。如果你想为其他主机名生成证书，或服务有多个访问入口：

sscg \
  --hostname server.example.com \
  --subject-alt-name www.example.com \
  --subject-alt-name api.example.com \
  --subject-alt-name IP:192.168.1.100

--subject-alt-name 可以重复使用，接受普通主机名以及 RFC 5280 格式的 IP 地址。这个参数在多宿主服务器或需要通过不同域名访问同一服务的场景中非常实用。

场景三：自定义文件路径

不想在当前目录生成一堆文件？把所有输出路径都指定清楚：

sscg \
  --hostname server.example.com \
  --ca-file /etc/pki/tls/certs/ca.crt \
  --cert-file /etc/pki/tls/certs/server.crt \
  --cert-key-file /etc/pki/tls/private/server.key

如果指定的文件已经存在，SSCG 默认会拒绝覆盖。加 --force 可以强制覆盖，但这个操作要谨慎使用。

进阶操作：加密、算法与客户端证书

场景四：为私钥设置密码

在生产环境中，私钥文件不应该以明文形式落盘。SSCG 支持通过密码保护私钥：

sscg \
  --hostname server.example.com \
  --cert-key-password-prompt

执行后会提示你输入密码。--cert-key-password-prompt 是比 --cert-key-password=明文 更安全的方式，因为后者会出现在进程列表中。同样，如果你选择保留 CA 私钥（通过 --ca-key-file 指定路径），也可以用 --ca-key-password-prompt 为其加密。

场景五：使用 ECDSA 密钥

从 4.0.0 版本开始，SSCG 支持 ECDSA 椭圆曲线密钥。ECDSA 在同等安全强度下密钥更短、签名和验证更快，适合性能敏感的场景：

sscg \
  --hostname server.example.com \
  --key-type ecdsa \
  --ec-curve secp384r1

支持的曲线包括 secp224r1、secp256r1、secp384r1、secp521r1。如果不指定 --ec-curve，SSCG 会使用默认曲线。

作为对比，传统的 RSA 密钥可以通过 --key-strength 调整强度（默认 2048 位，私有 CA 的最小建议值是 4096 位）：

sscg --hostname server.example.com --key-strength 4096

场景六：生成客户端认证证书

如果你的服务需要双向 TLS（mTLS）认证，SSCG 可以直接生成客户端证书对：

sscg \
  --hostname server.example.com \
  --client-file client.pem \
  --client-key-file client-key.pem

--client-file 生成的是一张由同一个临时 CA 签发的客户端认证证书。客户端在连接时出示这张证书，服务端通过验证 ca.crt 即可确认其身份。

文件管理与验证

理解输出文件的分工：

文件	用途	默认路径	建议权限
`ca.crt`	导入客户端信任库	`./ca.crt`	0644
`service.pem`	服务端公钥证书	`./service.pem`	0644
`service-key.pem`	服务端私钥	`./service-key.pem`	0600

SSCG 默认将证书文件设为 0644（可读），私钥文件设为 0600（仅所有者可读写），这是合理的默认值。如果需要调整，可以用 --ca-mode、--cert-mode、--cert-key-mode 等参数修改。

生成后可以用 OpenSSL 快速检查证书内容：

# 查看服务端证书的主题和备用名称
openssl x509 -in service.pem -noout -text | grep -A1 "Subject Alternative Name"

# 验证服务端证书确实由 ca.crt 签发
openssl verify -CAfile ca.crt service.pem

第二条命令如果返回 service.pem: OK，说明信任链完整，客户端导入 ca.crt 后就能正常验证该服务端证书。

版本差异与注意事项

SSCG 的版本迭代带来了一些行为变化，使用时需要注意：

4.0.0 之前：默认生成 Diffie-Hellman 参数文件（dhparams.pem），但这会拖慢生成速度。4.0.0 之后 DH 参数不再默认生成，需要时用 --dhparams-file 显式指定。
私有 CA 的 RSA 密钥强度：4.0.0 起，私有 CA 的最小 RSA 强度从 2048 位提升到 4096 位，以满足更严格的安全标准。
--package 参数：这是旧版本遗留的兼容参数，现在已经不再使用。如果你的脚本里有它，可以安全移除。

另外提醒一点：SSCG 生成的临时 CA 私钥默认被销毁，这是一个有意的安全设计。如果你确实需要保留 CA 私钥以便将来签更多证书，必须通过 --ca-key-file 显式指定保存路径，并建议配合密码保护。否则，每次运行 SSCG 都会创建一个全新的、独立的临时 CA。

实际应用场景

SSCG 的典型用例包括：

开发与测试环境：为本地服务快速生成受信任的 TLS 证书，无需购买商业证书或搭建完整的内部 CA。
内网服务：为内部管理界面、API 网关等提供加密传输，客户端只需导入一次 ca.crt 即可获得持续信任。
Cockpit 等工具的集成：Cockpit（Linux 的 Web 管理界面）在检测到 SSCG 可用时，会优先使用它来生成证书，而非直接创建自签名证书，以提升安全性。

SSCG 已经在主流 Linux 发行版中广泛可用，包括 Fedora、Debian、Arch Linux、Oracle Linux、ALT Linux 等，以 sscg 包名分发。

结语

SSCG 的价值在于它用一个“临时 CA”的巧妙设计，在“自签名证书的风险”和“搭建完整 PKI 的复杂度”之间找到了一个平衡点。它既不需要用户理解 openssl 命令的繁琐参数，也不需要维护一套长期运行的 CA 基础设施，却能让客户端以接近标准 PKI 的方式验证服务端身份。对于任何需要快速获得“可信但不复杂”的 TLS 证书的场景，SSCG 都是一个值得考虑的选择。