HTTPS starpniekserverim arī jāsūta sava sertifikātu ķēde

Diagnosticējiet trūkstošos starpsertifikātus TLS klausītājā no klienta uz Squid atsevišķi no galamērķa vietnes sertifikāta.

Ja klienti noraida HTTPS starpniekserveri pirms vietnes sasniegšanas, pārbaudiet ķēdi, ko sūta starpniekservera klausītājs. Viens derīgs lapas sertifikāts pats par sevi var nesniegt starpsertifikātus, kas klientam nepieciešami.

  1. Nosakiet pārbaudāmo galapunktu. Nolasiet resursdatora nosaukumu konfigurētajā starpniekservera URL un šī savienojuma kļūdu. Klausītāja sertifikātam jāaptver šis nosaukums. Vietnes sertifikāts vai cita IP aizstājvārda sertifikāts to nevar aizstāt.
  2. Pārbaudiet klausītāja ķēdes konfigurāciju. Squid atbalstītā OpenSSL konfigurācija var ietvert starpsertifikātus sertifikāta failā. Apstipriniet izkārtojumu klausītāja atsaucē instalētajai Squid versijai un TLS backend; pakotņu uzvedība nav vienāda. Squid 6.13 TLS klausītāja piemērs uztur klausītāja uzticību atsevišķi no galamērķa TLS.
  3. Pārbaudiet klienta uzticību atsevišķi. Starpsertifikātu sūtīšana palīdz veidot ķēdi, bet klientam joprojām nepieciešams paredzētais saknes uzticības enkurs. Visas servera ķēdes importēšana saknes krātuvē bez izšķiršanas ir cita izmaiņa nekā servera sūtītā labošana.

Atstājiet pārbaudi ieslēgtu. Tā identificē HTTPS starpniekserveri, ko klients bija iecerējis izmantot. Pēc šī savienojuma pārbaudes vēlāka vietnes sertifikāta kļūda pieder galamērķa TLS sesijai caur starpniekserveri, ar savu resursdatora nosaukuma un uzticības izmeklēšanu.

Saistītie raksti