Корпоративные прокси-серверы SSL вызывают ошибку ERR_TUNNEL_CONNECTION_FAILED после изменения сертификата?

Справочная информация: в некоторых комментариях указывается на путаницу с поведением обычных прокси, а не прокси-серверов проверки SSL: MITM ( Man In The Middle) прокси - это прокси, выполняющие перехват и проверку TLS / SSL .Они принимают клиентский запрос на целевой HTTPS-сайт и предоставляют (поддельный) сертификат от доверенного корневого центра сертификации (выбранный / созданный администратором и доверенный клиентом). а затем может прочитать - в открытом виде - любое сообщение между клиентом и целевым сайтом.

SSL Inspection имеет тенденцию реализовываться по-разному разными поставщиками: это не стандарт, и поэтому прокси-серверы MITM работают по-разному. Что обычно, так это то, что как только прокси завершает соединение с самим собой, он устанавливает новое соединение с целевым сайтом, используя свою собственную библиотеку и технологию SSL. Это «последнее» исходящее соединение - это соединение, которое будет определять поведение удаленного сайта.

Исходный ответ: TLS Указание имени сервера (SNI) еще не поддерживается всеми прокси, особенно старыми. Прокси-серверы, как правило, задерживаются еще долго после того, как они перестают поддерживаться, потому что они являются критически важной инфраструктурой и они работают, поэтому ...

Я предполагаю, что, включив SNI, вы могли предотвратить более раннюю проверку SSL - разрешили прокси с менее безопасными профилями подключения разрешать подключение. Если это можно решить, это ваш лучший путь к исправлению - например, в IIS существует концепция SSL-сертификата «по умолчанию», который используется в качестве запасного варианта, если SNI не находит совпадения. Если это не настроено для вас или если это возможно, это может быть лучше всего. Приносим извинения, это не соответствует вашей архитектуре.

Когда вы добавляете это к уже полузащитной проверке SSL прокси-сервером, который не понимает, что делает другой конец, или даже к чему-то простому, например, к тому, что прокси не может чтобы правильно разрешить имя, которое использовал клиент (несопоставимый DNS для прозрачной проверки SSL; клиент не намекает на имя сервера) ... да, я могу представить, что это может быть проблемой.

Я не уверен, как бы вы это сделали. отследить это, за исключением случаев анекдотического общения с администраторами ... кроме сбора сетевых трассировок настроек сеанса SSL на стороне вашего сервера, сопоставления их только с ошибками, а затем попытки "отследить" вызывающего абонента в случае очевидного сбоя ( обратный поиск IP в источнике, анализ трафика без SSL на предмет подсказок заголовка VIA и т.п.)

Во-первых, кэширование не может быть задействовано, поскольку вам (или, вернее, прокси) еще предстоит завершить квитирование TLS перед получением страниц.

Затем проверьте журналы вашего сервера, хотя там Это хорошая возможность, что вы ничего не найдете, кроме случаев, когда у вас включена отладка. Это связано с тем, что, поскольку при сбое клиентов еще не происходит рукопожатие, на ваш сервер не поступает HTTP-запрос.

Затем вы можете воспроизвести проблему самостоятельно? В таком случае устранение неполадок становится проще. Без возможности воспроизвести проблему,Мне удалось оставить tcpdump на некоторое время, собирая соединения, затем открывая полученный pcap и проверяя на наличие сбоев рукопожатия

И снимая в темноте, убедитесь, что ваше имя сервера / псевдоним правильно настроено на ваших HTTPS-хостах, и пока мы вы можете опубликовать вывод:

apachectl -S 

в своем вопросе?

Это все, что я могу предложить на основе ваших данных.