Even though we think we have a valid certificate, curl is still not liking it. Trying to ask here and see if there's any suggestion to debug the issue.
Here's the symptom
[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'
but the certificate seems to have the right hostname in it
[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
What could have caused curl to think the subject name is incorrect? Also adding our CSR for reference (Right, the IP was in the SAN... that is hopefully besides the point)
[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
Answering my own question, because the CSR has DNS.1 set, curl would look at SAN for all the possible DNS names. Therefore I need to also include myservice.companycloud.com in the SAN