Sertifikatfeil når du brukar ein proxy
Finn ut om verifiseringa feilar på TLS-sambandet til sjølve proxyen eller til målnettstaden før du endrar sertifikatinnstillingar.
Finn ut kva TLS-handhelsing som mislukkast før du endrar ein CA-pakke. Proxysertifikatet og nettstadsertifikatet kan verte kontrollerte på ulike samband.
| Proxy og mål | TLS-kontrollar |
|---|---|
| HTTP-proxy til eit HTTPS-mål | Verifiser målsertifikatet gjennom tunnelen etter CONNECT. |
| HTTPS-proxy til eit HTTPS-mål | Verifiser først TLS til proxyen; når tunnelen er opna, verifiserer du den separate TLS-økta til målet. |
Bruk den detaljerte sporinga til å finne det førespurde vertsnamnet og den sist fullførte handhelsinga. Ein sertifikatfeil på HTTPS-proxyen kan oppstå før nettstaden vert kontakta. Kontroller det tiltenkte namnet for sambandet, gyldigheitsperioden til sertifikatet, den lokale klokka, den venta kjeda og det godkjende tillitslageret. Ta med medvite konfigurert TLS-avskjering eller tillagde rotsertifikat i undersøkinga.
curl har separate CA-alternativ for dei to sambanda:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert fastset tillit for proxyen; --cacert for målet. Byt ut endepunktet og filene i dømet med verdiar frå tillitsoppsettet du vil bruke. Eigne pakkar er unødvendige når tilliten i systemet alt er tilstrekkeleg.
Å byte eit vertsnamn med ein vilkårleg IP endrar sertifikatsamsvaret. Å hoppe over verifisering kan skjule feilen utan å slå fast identiteten til motparten. For ein ukjend proxy er ei oppmoding om å installere rot-CA-en hans ikkje god nok grunn til å stole på han.
Ei avvist porttilkopling eller eit avvist CONNECT høyrer til eit tidlegare steg; sertifikatendringar løyser ikkje det. Omvendt gjeld ein HTTP-feil frå nettstaden etter vellukka mål-TLS-verifisering det mottekne svaret, ikkje endå ei CA-justering.