Хто надсилає клієнтський сертифікат через проксі?
Тримайте облікові дані mTLS призначення окремо від облікових даних проксі та від сертифікатів, які Apache використовує, коли створює власний висхідний сеанс TLS.
У звичайному HTTPS через CONNECT програма надсилає клієнтський сертифікат сайту під час власного рукостискання TLS із призначенням. Проксі лише пересилає байти; він не стає автоматично TLS-клієнтом сайту.
| Облікові дані | Власник/з’єднання |
|---|---|
| Ім’я користувача/пароль проксі | Доступ клієнта до проксі. |
| Клієнтський сертифікат і закритий ключ сайту | Сеанс TLS програми з призначенням. |
| Висхідний клієнтський сертифікат проксі-сервера | Сеанс TLS, який ініціює сам проксі. |
Ці ролі можуть співіснувати. Щоб mTLS до призначення працював, не потрібно завантажувати закритий ключ сайту на простий тунельний проксі. Після передавання CONNECT використовуйте звичайне налаштування клієнтського сертифіката призначення в програмі та продовжуйте перевіряти сертифікат сервера сайту.
SSLProxyMachineCertificateFile в Apache надає облікові дані, коли Apache створює власний висхідний сеанс TLS. Порада щодо цього файлу не доводить, що кожен клієнт, який використовує непрозорий тунель пересилання, повинен його налаштувати.
Перехоплення TLS завершує сеанс у посередника й змінює цю належність. Установіть, чи може потрібна ідентичність клієнта пройти крізь таку схему, замість припускати, що копіювання сертифіката зберігає автентифікацію від краю до краю.
У разі збою запишіть, чи запит зупинився на вході до проксі, на TLS призначення чи на пізнішому обміні програми. Розмістіть облікові дані на тому з’єднанні, яке справді їх вимагає.