HTTPS-prokurilo ankaŭ devas sendi sian atestilan ĉenon

Se klientoj malakceptas la HTTPS-prokurilon antaŭ ol atingi retejon, ekzamenu la ĉenon senditan de la prokurila aŭskultanto. Valida fina atestilo sola eble ne havigas la mezajn atestilojn, kiujn la kliento bezonas.

1. Identigu la kontrolatan finpunkton. Legu la gastignomon en la agordita prokurila URL kaj la eraron por tiu konekto. La atestilo de la aŭskultanto devas kovri tiun nomon. Atestilo de retejo aŭ atestilo por alia IP-kaŝnomo ne povas anstataŭigi ĝin.
2. Kontrolu la ĉenan agordon de la aŭskultanto. La subtenata OpenSSL-agordo de Squid povas inkluzivi mezajn atestilojn en la atestila dosiero. Konfirmu la aranĝon en la aŭskultanta referenco por la instalita Squid-eldono kaj TLS-malantaŭo; la konduto de pakaĵoj ne estas unuforma. La ekzemplo de TLS-aŭskultanto en Squid 6.13 tenas la fidon de la aŭskultanto aparte de la celloka TLS.
3. Kontrolu la klientan fidon aparte. Sendi mezajn atestilojn helpas konstrui la ĉenon, sed la kliento ankoraŭ bezonas la celitan radikan fid-ankron. Importi la tutan servilan ĉenon en radikan konservejon senescepte estas alia ŝanĝo ol korekti tion, kion la servilo sendas.

Lasu la kontroladon ŝaltita. Ĝi identigas la HTTPS-prokurilon, kiun la kliento intencis uzi. Post kiam tiu konekto kontroliĝos, posta reteja atestila eraro apartenas al la celloka TLS-kunsido tra la prokurilo, kun propra gastignoma kaj fida esploro.