Хто дасылае кліенцкі сертыфікат праз праксі?
Трымайце ўліковыя дадзеныя mTLS прызначэння асобна ад уліковых дадзеных праксі і ад сертыфікатаў, якія Apache выкарыстоўвае, калі стварае ўласную выходную TLS-сесію.
Для звычайнага HTTPS праз CONNECT праграма дасылае кліенцкі сертыфікат сайта падчас уласнага рукапаціску TLS з прызначэннем. Праксі перадае байты; ён не робіцца аўтаматычна TLS-кліентам сайта.
| Уліковыя дадзеныя | Уладальнік/злучэнне |
|---|---|
| Імя карыстальніка/пароль праксі | Доступ кліента да праксі. |
| Кліенцкі сертыфікат сайта і прыватны ключ | TLS-сесія праграмы з прызначэннем. |
| Выходны кліенцкі сертыфікат сервера праксі | TLS-сесія, якую ініцыюе само праксі. |
Гэтыя ролі могуць суіснаваць. Каб mTLS да прызначэння працаваў, не трэба загружаць прыватны ключ сайта ў просты тунельны праксі. Пасля перадачы CONNECT выкарыстоўвайце звычайную наладу кліенцкага сертыфіката прызначэння ў праграме і працягвайце правяраць сертыфікат сервера сайта.
SSLProxyMachineCertificateFile у Apache падае ўліковыя дадзеныя, калі Apache стварае ўласную выходную TLS-сесію. Парада пра гэты файл не даказвае, што кожны кліент, які выкарыстоўвае непразрысты прамы тунель, абавязаны яго наладзіць.
Перахоп TLS спыняе сесію на пасрэдніку і змяняе гэтую прыналежнасць. Устанавіце, ці можа патрабаваная ідэнтычнасць кліента прайсці праз такую схему, замест таго каб меркаваць, што капіраванне сертыфіката захоўвае аўтэнтыфікацыю ад канца да канца.
Пры збоі запішыце, ці спыніўся запыт на ўваходзе ў праксі, на TLS прызначэння ці на пазнейшым абмене праграмы. Размясціце ўліковыя дадзеныя на тым злучэнні, якое іх фактычна патрабуе.