In HTTPS-proxy moat ek syn sertifikaatkeatling stjoere

As klanten de HTTPS-proxy wegerje foardat se in website berikke, ûndersykje dan de keatling dy't de proxy-listener stjoert. In jildich bledsertifikaat allinnich leveret miskien net de tuskenlizzende sertifikaten dy't de klant nedich hat.

1. Identifisearje it kontrolearre einpunt. Lês de hostnamme yn 'e konfigurearre proxy-URL en de flater foar dy ferbining. It listener-sertifikaat moat dy namme dekke. In websitesertifikaat of sertifikaat foar in oare IP-alias kin it net ferfange.
2. Kontrolearje de keatlingkonfiguraasje fan de listener. De troch Squid stipe OpenSSL-konfiguraasje kin tuskenlizzende sertifikaten yn it sertifikaatbestân opnimme. Befestigje de opbou yn 'e listenerreferinsje foar de ynstallearre Squid-ferzje en TLS-backend; it gedrach fan pakketten is net gelyk. It TLS-listenerfoarbyld fan Squid 6.13 hâldt it fertrouwen fan 'e listener apart fan 'e TLS fan 'e bestimming.
3. Kontrolearje it fertrouwen fan de klant apart. Tuskenlizzende sertifikaten stjoere helpt by it bouwen fan 'e keatling, mar de klant hat noch altyd it bedoelde woartelfertrouwensanker nedich. It hiele serverkeatling sûnder ûnderskied ymportearje yn in woartelopslach is in oare feroaring as it rjochtmeitsjen fan wat de server stjoert.

Lit ferifikaasje oan stean. It identifisearret de HTTPS-proxy dy't de klant fan doel wie te brûken. Nei't dy ferbining ferifiearre is, heart in lettere websitesertifikaatflater by de TLS-sesje fan 'e bestimming fia de proxy, mei syn eigen hostnamme- en fertrouwensûndersyk.