Sertifikatfeil når du bruker en proxy
Finn ut om verifiseringen feiler på TLS-forbindelsen til selve proxyen eller til målstedet før du endrer sertifikatinnstillinger.
Finn ut hvilken TLS-håndhilsing som mislyktes før du endrer en CA-pakke. Proxyens sertifikat og nettstedets sertifikat kan bli kontrollert på ulike forbindelser.
| Proxy og mål | TLS-kontroller |
|---|---|
| HTTP-proxy til et HTTPS-mål | Verifiser målsertifikatet gjennom tunnelen etter CONNECT. |
| HTTPS-proxy til et HTTPS-mål | Verifiser først TLS til proxyen; når tunnelen er åpnet, verifiserer du den separate TLS-økten til målet. |
Bruk den detaljerte sporingen til å finne det forespurte vertsnavnet og den sist fullførte håndhilsingen. En sertifikatfeil på HTTPS-proxyen kan oppstå før nettstedet blir kontaktet. Kontroller det tiltenkte navnet for forbindelsen, sertifikatets gyldighetsperiode, den lokale klokken, den forventede kjeden og det godkjente tillitslageret. Ta med bevisst konfigurert TLS-avskjæring eller tillagte rotsertifikater i undersøkelsen.
curl har separate CA-alternativer for de to forbindelsene:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert angir tillit for proxyen; --cacert for målet. Bytt ut eksemplets endepunkt og filer med verdier fra tillitsoppsettet du har tenkt å bruke. Egne pakker er unødvendige når systemets tillit allerede er tilstrekkelig.
Å bytte et vertsnavn med en vilkårlig IP endrer sertifikatsamsvaret. Å hoppe over verifisering kan skjule feilen uten å fastslå identiteten til motparten. For en ukjent proxy er en anmodning om å installere dens rot-CA ikke god nok grunn til å stole på den.
En avvist portforbindelse eller et avvist CONNECT hører til et tidligere trinn; sertifikatendringer løser ikke det. Omvendt gjelder en HTTP-feil fra nettstedet etter vellykket mål-TLS-verifisering det mottatte svaret, ikke enda en CA-justering.