Кој го испраќа клиентскиот сертификат преку прокси?
Држете ги mTLS-акредитивите на одредиштето одвоени од акредитивите на проксито и од сертификатите што Apache ги користи кога создава сопствена излезна TLS-сесија.
Кај обичниот HTTPS преку CONNECT апликацијата го испраќа клиентскиот сертификат на веб-страницата за време на сопственото TLS ракување со одредиштето. Проксито само препраќа бајти; тоа не станува автоматски TLS-клиент на веб-страницата.
| Акредитив | Сопственик/врска |
|---|---|
| Корисничко име/лозинка за прокси | Пристап на клиентот до проксито. |
| Клиентски сертификат и приватен клуч на веб-страницата | TLS-сесија на апликацијата со одредиштето. |
| Излезен клиентски сертификат на прокси-серверот | TLS-сесија што самиот прокси ја иницира. |
Овие улоги можат да постојат заедно. Не е потребно да се качи приватниот клуч на веб-страницата на едноставно тунелско прокси за mTLS кон одредиштето да работи. По предавањето CONNECT, користете ја вообичаената конфигурација за клиентски сертификат на одредиштето во апликацијата и продолжете да го проверувате сертификатот на серверот на веб-страницата.
SSLProxyMachineCertificateFile на Apache обезбедува акредитиви кога Apache создава сопствена излезна TLS-сесија. Советите за таа датотека не докажуваат дека секој клиент што користи непрозирен тунел за проследување мора да ја конфигурира.
Пресретнувањето TLS завршува сесија кај посредник и ја менува оваа сопственост. Утврдете дали бараниот клиентски идентитет може да помине низ таков распоред, наместо да претпоставувате дека копирањето сертификат ја зачувува автентикацијата од крај до крај.
При неуспех забележете дали барањето запрело при најавата на проксито, при TLS на одредиштето или при подоцнежната размена на апликацијата. Ставете го акредитивот на врската што навистина го бара.