Certifikatfel när du använder en proxy
Ta reda på om det är TLS-anslutningen till själva proxyn eller till målwebbplatsen som inte klarar verifieringen innan du ändrar certifikatinställningar.
Ta reda på vilken TLS-handskakning som misslyckades innan du ändrar ett CA-paket. Proxyns certifikat och webbplatsens certifikat kan kontrolleras på olika anslutningar.
| Proxy och mål | TLS-kontroller |
|---|---|
| HTTP-proxy till ett HTTPS-mål | Verifiera målets certifikat genom tunneln efter CONNECT. |
| HTTPS-proxy till ett HTTPS-mål | Verifiera först TLS till proxyn; när tunneln har öppnats verifierar du den separata TLS-sessionen till målet. |
Använd den utförliga spårningen för att hitta det begärda värdnamnet och den senast slutförda handskakningen. Ett certifikatfel hos en HTTPS-proxy kan inträffa innan webbplatsen kontaktas. Kontrollera anslutningens avsedda namn, certifikatets giltighetstid, den lokala klockan, den förväntade kedjan och det godkända certifikatarkivet. Ta med avsiktligt konfigurerad TLS-avlyssning eller tillagda rotcertifikat i undersökningen.
curl har separata CA-alternativ för de två anslutningarna:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert anger betrodda certifikat för proxyn; --cacert för målet. Byt ut exemplets slutpunkt och filer mot värden från den tillitskonfiguration du avser att använda. Egna paket behövs inte om systemets tillit redan räcker.
Att byta ett värdnamn mot en godtycklig IP ändrar certifikatmatchningen. Att hoppa över verifiering kan dölja felet utan att fastställa motpartens identitet. För en okänd proxy är en begäran att installera dess rot-CA inte tillräcklig anledning att lita på den.
En nekad portanslutning eller ett avvisat CONNECT hör till ett tidigare steg; certifikatändringar kan inte lösa det. Omvänt hör ett HTTP-fel från webbplatsen efter verifierad TLS till det mottagna svaret, inte till ännu en CA-justering.