Kiu sendas la klientan atestilon tra prokura servilo?
Tenu la mTLS-legitimilojn de la celo aparte de la legitimiloj de la prokuro kaj de la atestiloj, kiujn Apache uzas kiam ĝi kreas sian propran suprenan TLS-sesion.
Ĉe ordinara HTTPS tra CONNECT, la aplikaĵo sendas la klientan atestilon de la retejo dum sia propra TLS-manpremo kun la celo. La prokuro nur transdonas bajtojn; ĝi ne aŭtomate fariĝas la TLS-kliento de la retejo.
| Legitimo | Posedanto/konekto |
|---|---|
| Uzantnomo/pasvorto de prokuro | Aliro de la kliento al la prokuro. |
| Klienta atestilo kaj privata ŝlosilo de la retejo | TLS-sesio de la aplikaĵo kun la celo. |
| Suprena klienta atestilo de la prokura servilo | TLS-sesio, kiun la prokuro mem komencas. |
Tiuj roloj povas kunekzisti. Ne necesas alŝuti la privatan ŝlosilon de la retejo al simpla tunela prokuro por funkciigi la celan mTLS. Post la transdono CONNECT, uzu la kutiman agordon de cela klienta atestilo de la aplikaĵo kaj daŭre kontrolu la servilan atestilon de la retejo.
SSLProxyMachineCertificateFile de Apache liveras legitimojn kiam Apache kreas sian propran suprenan TLS-sesion. Konsilo pri tiu dosiero ne pruvas, ke ĉiu kliento uzanta maldiafan antaŭenigan tunelon devas agordi ĝin.
Interkaptado de TLS finigas sesion ĉe peranto kaj ŝanĝas tiun posedon. Konstatu, ĉu la postulata klienta identeco povas trapasi tiun aranĝon, anstataŭ supozi, ke kopiado de atestilo konservas aŭtentikigon de unu fino al la alia.
Ĉe fiasko, notu ĉu la peto haltis ĉe la prokura ensaluto, ĉe la cela TLS aŭ ĉe la posta aplikaĵa interŝanĝo. Metu la legitimon sur la konekton, kiu efektive petas ĝin.