OpenSSL случайно не может проверить цепочку сертификатов URL на порту 443. Может ли быть проверена вся портовая информация экземпляра?

OpenSSL случайно не может проверить цепочку сертификатов URL на порту 443. Может ли быть проверена вся портовая информация экземпляра?

Надеюсь, кто-нибудь мне поможет, потому что я в растерянности. Моя команда страдает от проблем с отсутствием промежуточных сертификатов в наших сервисах. Мне было поручено написать скрипт, который будет постоянно проверять все URL-адреса наших сервисов с высоким трафиком один за другим, чтобы убедиться, что цепочка сертификатов завершена. Я написал программу на C#, которая запускала OpenSSL и анализировала вывод. Вот команда OpenSSL, которую я запускал для каждого URL-адреса:

"openssl.exe s_client -showcerts -servername " + uri + " -verify_hostname " + uri + " -connect " + uri +":" + port

Или

openssl.exe s_client -showcerts -servername www.euro-example-01.com -verify_hostname www.euro-example-01.com -connect www.euro-example-01.com:443

Порт по умолчанию 443 и используется в 99% случаев. Если OpenSSL когда-либо вернет “Verify return code: 21 (unable to verify the first certificate)”, я буду знать, что промежуточный сертификат отсутствует, и будет запущено оповещение. Кроме того, OpenSSL выводит цепочку для меня, чтобы проверить это. Это сработало при тестировании на таких сайтах, как incomplete-chain.badssl.com.

Теперь он постоянно работает в облаке и время от времени выдает оповещения. Однако, много раз наш сервисный инженер будет проверять каждый сервер неисправного URL, используя порт экземпляра, и мы найдем0 случаев, когда это не удается. Мы используем циклическую балансировку нагрузки, так не должны ли мы ожидать, что по крайней мере один из этих отдельных серверов станет причиной сбоя 443? Журналы OpenSSL из случая сбоя :443 показывают только один сертификат в цепочке, а такие сайты, как SSLLabs, также подтвердили отсутствие промежуточного звена.

Если бы наш инженер перезагрузил проблемную конечную точку(и), то была бы найдена вся цепочка, и оповещения об отсутствующих промежуточных звеньях исчезли бы.

Возможно, самое странное, что я настроил отдельный скрипт для проверки всего 4 URL вместо всех ~160 различных URL. Вчера в течение 30 минут euro-example-01.com:443был протестирован 12 раз и 6 из них провален на оригинальном скрипте. За те же 30 минут на новом, меньшем по размеру тесте скрипт euro-example-01.com:443был протестирован 12 раз и все 12 раз пройден. Возможно, два скрипта просто обращаются к разным серверам, но мне это кажется подозрительным.

Как я уже сказал, мы не понимаем, почему это происходит. Я попросил нашего сервисного инженера проверить балансировщик нагрузки, и он сказал, что он работает нормально. Мы не обнаружили никакой закономерности, которая заставляет тесты давать сбои. Есть ли у кого-нибудь из вас идея, почему это происходит? Или есть ли способ узнать, какой порт экземпляра задействован, когда мы тестируем с использованием :443? Возможно, нам придется перейти на тестирование на портах экземпляра вместо :443, но количество наших экземпляров регулярно меняется, и их большое количество.

Заранее благодарю за любую помощь!

вкратце: Порт 443 в нашем URL-адресе не возвращает промежуточный сертификат, но когда мы проверяем отдельные серверы на наличие указанного URL-адреса, промежуточный сертификат всегда находится.

Связанный контент