Странное несоответствие общего имени SSL
Сегодня я столкнулся со странным случаем несоответствия cn. У меня два домена:
kpmg.talentsource.rs и www.kpmg.talentsource.rs
оба имеют prod.q.ssl.global.fastly.net в качестве CNAME у них одинаковые записи и сертификаты.
Тем не менее:
https://kpmg.talentsource.rs (ОК)
https://www.kpmg.talentsource.rs (несоответствие CN)
https://www.ssllabs.com/ssltest/analyze.html?d=kpmg.talentsource.rs&s=151.101.65.62https://www.ssllabs.com/ssltest/analyze.html?d=www.kpmg.talentsource.rs&s=151.101.65.62
Примечание: ни один из этих двух не имеет файла kpmg.talentsource.rs ни в CN, ни в SAN.
Есть идеи, почему это происходит?
Удалил комментарии, потому что они вводили в заблуждение. Ответ кажется правильным :)
Ответы 1
Сертификат имеет альтернативное имя субъекта *.talentsource.rs (среди многих других несвязанных).
Согласно правилам X.509 / TLS, * соответствует только одному уровню / метке, он не пересекает точку, так сказать. Итак, *.talentsource.rs соответствует имени хоста kpmg.talentsource.rs, но НЕТwww.kpmg.talentsource.rs, отсюда и ошибка браузера.
Вам нужно либо добавить www.kpmg.talentsource.rs или *.kpmg.talentsource.rs в качестве SAN (обратите внимание, что talentsource.rs уже есть в списке) в этом сертификате, либо вообще прекратить использование www.kpmg.talentsource.rs (перенаправление не решит проблему, так как вам все еще нужно сначала выполнить рукопожатие TLS. перед получением HTTP-заголовка Location:, поэтому вам все равно нужен соответствующий сертификат).
@TheNewOne Я не владею серверами. Мне просто любопытно. Независимо от этого, мне интересно узнать, почему сертификат не работает, а не почему сервер возвращает 500 при подключении, что не должно требовать доступа к серверу. например как хром определяет, что сертификат первого домена хороший, а второй - плохой?