curl报SSL错误51：证书主题名称不匹配的排查请求

尽管我们认为配置的SSL证书有效，但curl无法正常识别，请求排查建议。

问题现象 #

执行curl命令报错：

[root@myclient whitelist]# curl -I https://myservice.companycloud.com:443
curl: (51) SSL: no alternative certificate subject name matches target host name 'myservice.companycloud.com'

但通过openssl验证，证书似乎包含正确的主机名：

[root@myclient whitelist]# openssl s_client -connect myservice.companycloud.com:443 -showcerts
CONNECTED(00000003)
depth=1 CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC
verify return:1
depth=0 CN = myservice.companycloud.com, C = us, L = Cloud City, O = Cloud Corporation, ST = ABC
verify return:1
---
Certificate chain
 0 s:CN = myservice.companycloud.com, C = us, L = Cloud City, O = Cloud Corporation, ST = ABC
   i:CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC
-----BEGIN CERTIFICATE-----
.....
-----END CERTIFICATE-----
 1 s:CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC
   i:CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN = myservice.companycloud.com, C = us, L = Cloud City, O = Cloud Corporation, ST = ABC

issuer=CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC

---
Acceptable client certificate CA names
CN = myservice.companycloud.com, C = us, L = Cloud City, O = Cloud Corporation, ST = ABC
CN = companycloud.com, C = us, O = Cloud Corporation, ST = ABC
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:0x1A+0x08:0x1B+0x08:0x1C+0x08:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5500 bytes and written 458 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 51CAB0D8E5A042D32D59507B87423D75EC4A524335716D199EA999BF10226EF9
    Session-ID-ctx:
    Resumption PSK: B8BBCFCEBBF08AD172F8858DD0AF96EE7311D2C578D38B2D0833FD4DCBDD7EF8001039C5FC776B4D52B52263BDB1DA35
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 84 60 dd 7c 37 ee bf 0e-46 34 29 f4 52 a0 f6 6f   .`.|7...F4).R..o
    0010 - 26 c2 c1 1a 5e 75 b4 69-76 66 9e 29 4b c0 36 e2   &...^u.ivf.)K.6.

    Start Time: 1724963941
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 97F1A0C483BBDB50FF7E59EB08CC0EF93F263191DF6236D469E56D303CA18858
    Session-ID-ctx:
    Resumption PSK: F75C4F9F435106F4EC197EC493E6DED5E967E73743A0FF74454BFC6886CBC9B24D415949072BF53444CC103B45F4ABEA
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 50 06 95 05 23 3c 75 00-3c 86 43 ef 13 5c a9 d9   P...#<u.<.C..\..
    0010 - fb 1c fb a2 dd e1 bd 95-e8 fd 3e f5 d3 b2 d9 17   ..........>.....

    Start Time: 1724963941
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
closed

附上CSR配置（IP在SAN中，本应无关）：

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
 
[req_distinguished_name]
C = US
ST = ABC
L= Cloud City
O = Cloud Corporation
CN = myservice.companycloud.com
 
[v3_req]
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = host_short_name
IP.1  = 10.123.123.123

核心原因 #

现代工具（包括curl）验证SSL证书时，优先检查Subject Alternative Name（SAN）扩展，而非传统的Common Name（CN）字段。你的CSR配置中，SAN的DNS条目仅为host_short_name，完全不包含myservice.companycloud.com，这直接导致curl验证失败。

openssl的s_client命令默认只验证证书链有效性，不会严格校验SAN与请求主机名的匹配关系，因此会显示verify return code: 0 (ok)，但不代表主机名匹配验证通过。

解决步骤 #

1. 修改CSR配置文件，在alt_names段中添加正确的主机名：

[alt_names]
DNS.1 = myservice.companycloud.com
DNS.2 = host_short_name  # 保留原有短名称（如果业务需要）
IP.1  = 10.123.123.123

2. 重新生成CSR，使用更新后的配置文件：

openssl req -new -key your_private_key.key -out your_new_csr.csr -config updated_csr_config.ini

3. 重新签署证书，若为CA签发则提交新CSR申请，若为自签证书则执行：

openssl x509 -req -in your_new_csr.csr -CA your_ca_cert.pem -CAkey your_ca_key.key -CAcreateserial -out new_server_cert.pem -days 365 -extensions v3_req -extfile updated_csr_config.ini

4. 替换服务器证书，将新证书部署到服务端并重启相关服务（如Nginx、Apache等）。

5. 验证修复效果：

curl -I https://myservice.companycloud.com:443

此时应不再出现SSL证书主题名称不匹配的错误。

内容的提问来源于stack exchange，提问作者user1763590