Я надеюсь, что кто-то может мне помочь, потому что я в растерянности. Моя команда страдала от проблем с отсутствием промежуточных сертификатов в наших услугах. Мне было поручено написать сценарий, который будет постоянно тестировать все наши 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, но наши счетчики экземпляров регулярно меняются, и их очень много.
Заранее благодарим вас за любую помощь, которую вы можете оказать!
tl; dr: Порт 443 в нашем URL-адресе не будет возвращать промежуточный сертификат, но когда мы проверяем отдельные серверы для указанного URL-адреса, промежуточный сертификат всегда находится.