HTTPS прокси също трябва да изпраща своята верига от сертификати

Ако клиентите отхвърлят HTTPS проксито, преди да достигнат до сайт, прегледайте веригата, която изпраща слушателят на проксито. Един валиден краен сертификат може да не предоставя междинните сертификати, от които клиентът се нуждае.

1. Определете проверяваната крайна точка. Прочетете името на хоста в конфигурирания URL на проксито и грешката за тази връзка. Сертификатът на слушателя трябва да покрива това име. Сертификат на сайт или сертификат за друг IP псевдоним не може да го замени.
2. Проверете конфигурацията на веригата на слушателя. Поддържаната от Squid конфигурация на OpenSSL може да включва междинни сертификати във файла на сертификата. Потвърдете подредбата в справката за слушателя за инсталираната версия на Squid и TLS бекенда; поведението на пакетите не е еднакво. Примерът за TLS слушател в Squid 6.13 държи доверието на слушателя отделно от TLS на дестинацията.
3. Проверете доверието на клиента отделно. Изпращането на междинни сертификати помага за изграждане на веригата, но клиентът все още се нуждае от предвидената основна котва на доверие. Импортирането на цялата сървърна верига в хранилище за корени безразборно е друга промяна, различна от коригирането на това, което сървърът изпраща.

Оставете проверката включена. Тя идентифицира HTTPS проксито, което клиентът е възнамерявал да използва. След като тази връзка се провери, по-късна грешка в сертификата на сайта принадлежи на TLS сесията на дестинацията през проксито, със собствено изследване на името на хоста и доверието.