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