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