Napake potrdil pri uporabi posrednika
Preden spremenite nastavitve potrdil, ugotovite, ali je spodletelo preverjanje povezave TLS s posrednikom ali s ciljnim spletnim mestom.
Pred spreminjanjem svežnja CA ugotovite, katero rokovanje TLS je spodletelo. Potrdilo posrednika in potrdilo spletnega mesta se lahko preverjata na različnih povezavah.
| Posrednik in cilj | Preverjanja TLS |
|---|---|
| Posrednik HTTP za cilj HTTPS | Po CONNECT preverite potrdilo cilja skozi tunel. |
| Posrednik HTTPS za cilj HTTPS | Najprej preverite TLS do posrednika; po odprtju tunela preverite ločeno sejo TLS do cilja. |
S podrobnim sledenjem ugotovite zahtevano ime gostitelja in zadnje dokončano rokovanje. Napaka potrdila posrednika HTTPS se lahko pojavi pred stikom s spletnim mestom. Preverite predvideno ime te povezave, obdobje veljavnosti potrdila, lokalno uro, pričakovano verigo in odobreno shrambo zaupanja. V preiskavo vključite tudi namerno nastavljeno prestrezanje TLS ali dodano korensko potrdilo.
curl ponuja ločene možnosti CA za obe povezavi:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert določa zaupanje za posrednika; --cacert za cilj. Vzorčno končno točko in datoteke zamenjajte z vrednostmi iz predvidene nastavitve zaupanja. Lastni svežnji niso potrebni, če sistemsko zaupanje že zadošča.
Zamenjava imena gostitelja s poljubnim IP spremeni ujemanje potrdila. Izpustitev preverjanja lahko skrije napako, ne da bi potrdila identiteto druge strani. Pri neznanem posredniku zahteva za namestitev njegovega korenskega CA ni zadosten razlog za zaupanje.
Zavrnjena povezava na vrata ali zavrnjen CONNECT sodita v zgodnejšo fazo; spremembe potrdil tega ne odpravijo. Obratno pa se HTTP napaka spletnega mesta po preverjenem TLS cilja nanaša na prejeti odgovor, ne na novo prilagoditev CA.