Є сервер під windows і є центр сертифікації у них в організації і треба було просто перевипустити сертифікат для одного із сервісів. Нічого складного, але щось пішло не так і браузери постійно скаржилися на SSL-зʼєднання.
В першу чергу перевірив чи новий сертифікат підписаний саме тим CA, який у них:
openssl verify -verbose -CAfile ca_ad.crt newcrt.crt
client
X509v3 Authority Key Identifier:
5A:E5:8A:6D:B0:93:BF:58:8C:88:06:B4:28:99:05:13:4F:1A:B6:9F
ca
X509v3 Subject Key Identifier:
5A:E5:8A:6D:B0:93:BF:58:8C:88:06:B4:28:99:05:13:4F:1A:B6:9F
Все збігається, йдемо далі. Перевіримо, що скаже curl, якщо йому примусово підсунути ще наш CA:
> curl.exe -I --cacert root-ca-chain.pem https://zabbix.domain.local curl: (60) SSL: no alternative certificate subject name matches target hostname 'zabbix.domain.local'
І тут все стало на свої місця: домен був лише в Subject Common Name (CN) і не було в Subject Alternative Name (SAN) , а оскільки зараз майже ніхто не “дивиться” в CN, то маємо проблему. Доречі, саме це і збило з пантелику системного адміністратора, оскільки він бачив домен в CN, але не очікував, що треба, щоб домен був саме в SAN полі. Після правильної генерації сертифіката все запрацювало, як треба.
Тобто, резюмуючи, якщо генеруєте SSL-сертифікат то обовʼязково вказуйте все в SAN, навіть те, що ВЖЕ вказали в CN.