Atestilaj eraroj dum uzado de prokurilo
Antaŭ ŝanĝi atestilajn agordojn, identigu ĉu malsukcesis kontrolo de la TLS-konekto al la prokurilo mem aŭ al la cela retejo.
Antaŭ ŝanĝi CA-pakon, trovu kiu TLS-manpremo malsukcesis. La prokurila atestilo kaj la reteja atestilo povas esti kontrolataj sur malsamaj konektoj.
| Prokurilo kaj celo | TLS-kontroloj |
|---|---|
| HTTP-prokurilo al HTTPS-celo | Post CONNECT, kontrolu la celan atestilon tra la tunelo. |
| HTTPS-prokurilo al HTTPS-celo | Unue kontrolu TLS al la prokurilo; post malfermo de la tunelo, kontrolu la apartan TLS-seancon al la celo. |
Uzu la detalan spuron por identigi la petitan gastignomon kaj la lastan finitan manpremon. Atestila eraro de HTTPS-prokurilo povas okazi antaŭ kontakto kun la retejo. Kontrolu la celitan nomon de tiu konekto, la validecperiodon de la atestilo, la lokan horloĝon, la atendatan ĉenon kaj la aprobitan fidodeponejon. Enmetu en la esploron ankaŭ intence agorditan TLS-interkapton aŭ aldonitan radikan atestilon.
curl ofertas apartajn CA-opciojn por la du konektoj:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert liveras la fidobazon por la prokurilo; --cacert por la celo. Anstataŭigu la ekzemplan finpunkton kaj dosierojn per valoroj el la celita fidoaranĝo. Propraj pakoj estas nenecesaj kiam la sistema fido jam sufiĉas.
Anstataŭigi gastignomon per arbitra IP ŝanĝas la atestilan kongruigon. Preterlasi kontrolon povas kaŝi la malsukceson sen konfirmi la identecon de la alia flanko. Por nekonata prokurilo, peto instali ĝian radikan CA ne estas sufiĉa kialo fidi ĝin.
Rifuzita pordokonekto aŭ malakceptita CONNECT apartenas al pli frua etapo; ŝanĝi atestilojn ne povas ripari tion. Inverse, post kontrolo de la cela TLS, reteja HTTP-eraro apartenas al la ricevita respondo, ne al plia CA-alĝustigo.