Certifikatfejl ved brug af en proxy
Find ud af, om det er TLS-forbindelsen til selve proxyen eller til målwebstedet, der fejler ved verificeringen, før du ændrer certifikatindstillinger.
Find den TLS-handshake, der mislykkedes, før du ændrer en CA-bundle. Proxyens og webstedets certifikater kan blive kontrolleret på forskellige forbindelser.
| Proxy og mål | TLS-kontroller |
|---|---|
| HTTP-proxy til et HTTPS-mål | Verificer målcertifikatet gennem tunnelen efter CONNECT. |
| HTTPS-proxy til et HTTPS-mål | Verificer først TLS til proxyen; verificer derefter den separate TLS-session til målet, når tunnelen er åbnet. |
Brug den detaljerede sporing til at finde det anmodede værtsnavn og den senest fuldførte handshake. En certifikatfejl ved en HTTPS-proxy kan opstå, før webstedet kontaktes. Kontroller forbindelsens tilsigtede navn, certifikatets gyldighedsperiode, det lokale ur, den forventede kæde og det godkendte tillidslager. Medtag bevidst konfigureret TLS-interception eller tilføjede rodcertifikater i undersøgelsen.
curl har separate CA-indstillinger til de to forbindelser:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert angiver tilliden til proxyen; --cacert tilliden til målet. Erstat eksemplets endepunkt og filer med værdier fra den ønskede tillidsopsætning. Egne bundler er unødvendige, når systemets tillid allerede er tilstrækkelig.
Hvis du erstatter et værtsnavn med en vilkårlig IP, ændres certifikatmatchningen. At springe verificering over kan skjule fejlen uden at fastslå modpartens identitet. For en ukendt proxy er en anmodning om at installere dens rod-CA ikke tilstrækkelig grund til at stole på den.
En afvist portforbindelse eller et afvist CONNECT hører til et tidligere trin; det kan certifikatændringer ikke løse. Omvendt hører en HTTP-fejl fra webstedet efter verificeret mål-TLS til det modtagne svar og ikke til endnu en CA-justering.