У нас есть клиент, который заходит на наш сайт и получает ERR_CERT_COMMON_NAME_INVALID. Оказывается, когда клиент заходит в наше приложение, он получает SSL, который не исходит от нас. Сначала это было для домена, *.adperfect.comа затем *.ni.a1q7.net(оба из них нам не знакомы). Мы используем облако AWS, наши маршруты обрабатываются через ALB, а наши сертификаты также через AWS. Ни один другой клиент не сталкивается с чем-либо подобным.
Это происходит с клиентом в Chrome, в режиме инкогнито тоже, при использовании другого браузера, даже при использовании телефона с интернетом, а не только с их Wi-Fi. Они клянутся, что не устанавливали ничего подозрительного, и очистка кэша или данных не имеет значения. Все это выглядит крайне подозрительно, но, честно говоря, я не могу сказать, что здесь может происходить. Как что-то подобное вообще происходит? Клиент настаивает, что это происходит только тогда, когда он пытается войти в наш сервис и ни в какой другой. Я готов поверить, что у нас что-то неправильно настроено, но как и почему это вообще может означать отправку совершенно случайного сертификата ssl, которого у нас нет, уму непостижимо.
Есть идеи, что это может быть? Кто-нибудь сталкивался с чем-то подобным?
решение1
Вы не «получаете SSL» — вам предоставляется сертификат (TLS или x509).
Сначала это был домен *.adperfect.com, а затем *.ni.a1q7.net (оба из которых нам не знакомы).
Вы проверили, онитолькопользователи, на которых это повлияло? Точнее, вы тестировали это за пределами ваших текущих сетей?
Мы используем облако AWS
Который является общим ресурсом, поэтому онмощьбыть проблема конфигурации на удаленном конце. Первый домен (по крайней мере частично) размещен на AWS. Не могу найти никаких имен для последнего.
ПРЕДПОЛАГАЯ, что они единственные, кого это затронуло, то первым делом вам нужно проверить, видят ли они те же записи DNS, что и все остальные. Запуск nslookup yoursite.example.comсообщит вам и им, во что преобразуется имя. Также было бы неплохо попросить затронутого клиента отправить вам копию предоставленного ему сертификата, на всякий случай, если он использует какой-нибудь сомнительный продукт MITM для защиты от вредоносного ПО.
Вам также следует проверить конфигурацию ALB.
решение2
Возможно, возникла проблема с разрешением DNS, поскольку оба перечисленных вами домена также являются доменами AWS Route53:
$ host -t ns adperfect.com
adperfect.com name server ns-1304.awsdns-35.org.
adperfect.com name server ns-1893.awsdns-44.co.uk.
adperfect.com name server ns-240.awsdns-30.com.
adperfect.com name server ns-934.awsdns-52.net.
$ host -t ns ni.a1q7.net
ni.a1q7.net name server ns-1405.awsdns-47.org.
ni.a1q7.net name server ns-1852.awsdns-39.co.uk.
ni.a1q7.net name server ns-264.awsdns-33.com.
ni.a1q7.net name server ns-736.awsdns-28.net.
$
Может быть, в IP-адресе разрешения имени есть опечатка?