Кто отправляет клиентский сертификат через прокси?
Держите учётные данные mTLS назначения отдельно от учётных данных прокси и от сертификатов, которые Apache использует при создании собственного исходящего сеанса TLS.
При обычном HTTPS через CONNECT приложение отправляет клиентский сертификат сайта во время собственного рукопожатия TLS с назначением. Прокси лишь пересылает байты; он не становится автоматически TLS-клиентом сайта.
| Учётные данные | Владелец/соединение |
|---|---|
| Имя пользователя/пароль прокси | Доступ клиента к прокси. |
| Клиентский сертификат и закрытый ключ сайта | Сеанс TLS приложения с назначением. |
| Исходящий клиентский сертификат прокси-сервера | Сеанс TLS, который инициирует сам прокси. |
Эти роли могут сосуществовать. Чтобы mTLS до назначения работал, не нужно загружать закрытый ключ сайта в простой туннельный прокси. После передачи CONNECT используйте обычную настройку клиентского сертификата назначения в приложении и продолжайте проверять сертификат сервера сайта.
SSLProxyMachineCertificateFile в Apache предоставляет учётные данные, когда Apache создаёт собственный исходящий сеанс TLS. Совет об этом файле не доказывает, что каждый клиент, использующий непрозрачный форвардный туннель, обязан его настроить.
Перехват TLS завершает сеанс у посредника и меняет эту принадлежность. Установите, может ли требуемая идентичность клиента пройти через такую схему, вместо того чтобы предполагать, что копирование сертификата сохраняет сквозную аутентификацию.
При сбое запишите, остановился ли запрос на входе в прокси, на TLS назначения или на последующем обмене приложения. Поместите учётные данные в то соединение, которое действительно их требует.