curl: (60) SSL: 无法从对等证书获取通用名称

看起来你遇到的是自签名证书配置里的常见小问题——证书的通用名称（CN）为空，导致curl和wget这类客户端没法验证证书和请求的域名匹配。咱们一步步来排查解决：

问题根源分析 #

从wget的报错ERROR: certificate common name ‘’ doesn't match requested host name ‘example.com’就能明确看出来：你生成的证书里根本没设置对应的通用名称字段，或者配置文件里的CN项直接缺失了。另外现在很多现代客户端（包括新版本的curl）会优先检查Subject Alternative Name（SAN）扩展，就算CN配置正确，没加SAN也可能触发验证失败。

修复步骤 #

1. 修正你的server.cnf配置文件

你之前的配置里缺了commonName字段，还没配置关键的SAN扩展，把配置改成下面这样：

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
countryName=            <country>
stateOrProvinceName=    <province>
localityName=           <locality>
organizationName=       <organization>
commonName=             example.com  # 这里必须填你的域名，比如example.com

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:example.com  # 添加SAN扩展，适配现代客户端的验证逻辑

2. 重新生成证书和密钥

用openssl命令重新生成符合要求的自签名证书：

openssl req -new -x509 -days 365 -keyout server.key -out server.crt -config server.cnf

生成后可以用下面的命令验证证书是否正确配置了CN和SAN：

openssl x509 -in server.crt -text -noout

在输出里找这两个部分：

• Subject字段应该包含CN=example.com
• X509v3 Subject Alternative Name应该显示DNS:example.com

3. 更新web服务器配置

把新生成的server.crt和server.key替换到你的web服务器（比如Nginx、Apache）的SSL配置里，然后重启服务让配置生效。

4. 测试验证

因为是自签名证书，系统默认不信任，所以测试时需要指定信任这个证书：

curl --noproxy "*" --cacert server.crt https://example.com

wget的话可以用：

wget --no-proxy --ca-certificate=server.crt https://example.com

如果不想每次都加证书参数，也可以把server.crt添加到系统的信任证书库中（不同系统操作不同，比如Ubuntu是放到/usr/local/share/ca-certificates/然后运行update-ca-certificates）。

备注：内容来源于stack exchange，提问作者Seal_bebbe