什么是SSL自签名证书？

SSL自签名证书是指由个人或组织自行签发而非由受信任的第三方CA（证书颁发机构）颁发的数字证书。举个例子，就像你自己写了一张"我是好人"的证明并签字，而不是去公安局开具无犯罪记录证明——前者是自签名，后者是权威机构认证。

在企业内部网络、开发测试环境或特定场景下，使用自签名证书是一种常见做法。比如开发人员小王在本地搭建测试网站时，不想花钱购买商业证书，就会生成一个自签名证书来启用HTTPS。

CN字段的含义与重要性

CN（Common Name）是SSL证书中最重要的字段之一，它必须准确匹配要保护的主机名或域名。这就像身份证上的姓名必须与你本人一致一样重要。

举个例子：

- 正确配置：CN=www.example.com

- 错误配置：CN=服务器1号

当用户访问https://www.example.com时，浏览器会检查证书中的CN是否与该域名匹配。如果不匹配，就会出现警告提示。

CN字段的常见安全隐患

1. 通配符滥用问题

有些管理员为了方便会使用通配符CN如*.example.com来覆盖所有子域名。这在某些情况下确实方便，但存在安全风险：

```shell

不推荐的泛域名配置示例

openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out cert.pem \

-subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=*.example.com"

```

这种配置意味着任何子域都可以使用同一张证书，如果私钥泄露影响范围极大。

2. IP地址作为CN的问题

在内网环境中常见将IP地址设为CN值：

IP作为CN的示例（不推荐）

-subj "/C=CN/ST=Beijing/L=Beijing/O=MyCompany/CN=192.168.1.100"

现代浏览器对这种做法越来越严格限制，Chrome等浏览器会直接显示严重警告。

3. CN与实际访问地址不匹配

这是最常见的错误之一：

CN设置为test.example.com

openssl req ... -subj "/.../CN=test.example.com"

但实际用该证书部署在dev.example.com上

这种情况会导致每个访问者都看到"此网站不安全"的红色警告。

SAN扩展的正确使用方法

现代最佳实践是使用主题备用名称(SAN)扩展而非依赖单一的CN字段。这就像在你的身份证上不仅有姓名(CN)，还有身份证号、住址等其他识别信息。

正确生成包含SAN的自签名证书示例：

cat > openssl.cnf <

[req]

distinguished_name = req_distinguished_name

x509_extensions = v3_req

prompt = no

[req_distinguished_name]

C = CN

ST = Beijing

L = Beijing

O = MyCompany

OU = IT Dept

CN = www.example.com

[v3_req]

keyUsage = keyEncipherment, dataEncipherment, digitalSignature

extendedKeyUsage = serverAuth

subjectAltName = @alt_names

[alt_names]

DNS.1 = www.example.com

DNS.2 = example.com

IP.1 = 192.168.1.100

EOF

openssl req -x509 -nodes -days 3650 \

-newkey rsa:2048 \

-keyout server.key \

-out server.crt \

-config openssl.cnf \

-extensions v3_req

这个例子同时包含了：

- CN字段(www.example.com)

- DNS类型的SAN(www.example.com和example.com)

- IP类型的SAN(192.168.1.100)

企业内网的最佳实践建议

1. 建立私有CA：与其每台服务器都使用独立的自签名证书，不如建立一个内部CA统一签发。这相当于在企业内部设立一个"小公安局"，所有部门都认可它颁发的证件。

2. 严格控制私钥：私钥如同保险柜钥匙，应当设置适当权限(如600)，并限制知晓人员范围。

3. 定期轮换：即使在内网也应定期更换证书（建议不超过1年），减少密钥泄露的风险影响时间窗口。

4. 明确的命名规范：

```shell

Good example (清晰明确的命名)

/C=CN/ST=Sichuan/L=Chengdu/O=A Company/OU=IT Department/CN=vpn.acompany.internal

Bad example (含糊不清的命名)

/C=US/O=Some Company/OU=None/CN=vpnserver

```

5. 禁用弱算法：

避免使用SHA-1等已被证明不安全的哈希算法：

Deprecated (已废弃)

openssl req ... -sha1 ...

Recommended (推荐)

openssl req ... -sha256 ...

Chrome/Firefox对自签名证书的处理变化

近年来主流浏览器对自签名证书的限制越来越严格：

- Chrome从58版本开始不再信任仅有CommonName没有SAN扩展的SSL/TLS证书。

- Firefox错误代码SEC_ERROR_UNKNOWN_ISSUER通常表示无法验证签发者身份。

- iOS设备要求必须包含SAN扩展才能正常识别。

这意味着传统的仅设置CN的方式已经不能满足现代浏览器的安全要求了。

自动化工具推荐与管理技巧

对于需要管理大量自签名证书的环境，可以考虑以下工具：

1. Certbot：虽然是针对Let's Encrypt设计，但可以学习其自动化管理思路。

2. OpenSSL包装脚本：编写符合自己企业规范的脚本模板：

```bash

!/bin/bash

DOMAIN=$1

openssl req ... \

-subj "/C=XX/O=${DOMAIN}/OU=$(date +%Y)/CN=${DOMAIN}" \

...

echo "Certificate for ${DOMAIN} generated!"

3. Ansible/Vault集成：将密钥管理与配置管理工具结合实现自动化部署和安全存储。

与决策建议

在选择是否使用自签名证书时需要考虑以下因素：

? 适合场景：

- 内部测试环境

- IoT设备初始配置

- VPN等纯内网服务

- CI/CD流水线中的临时需求

? 不适合场景：

- 面向公众的商业网站

- API服务需要第三方集成的场合

- SaaS产品中客户可访问的部分

记住一条黄金法则："如果你的用户需要手动安装或信任你的根证书才能正常访问网站功能体验完整的话"，那么你应该重新考虑是否真的需要使用自签名方案——也许一个便宜的DV证书或者Let's Encrypt免费方案会是更好的选择。"

对于必须使用的情况请务必遵循本文介绍的最佳实践规范特别是关于SAN扩展的使用这对避免各种奇怪的浏览器兼容性问题至关重要。"

TAG:ssl自签名证书cn直,ssl证书自签发,https 自签名证书,自动生成ssl证书