http.check-revoke styr kontrollen av certifikatåterkallelse i Windows. Att sätta den till false ändrar valideringspolicyn. Den hittar ingen proxy, väljer inte dess protokoll och installerar inte organisationens CA.

Därför måste ett recept som innehåller både en proxy-URL och check-revoke = false läsas som två separata ändringar. Om avstängningen av kontrollen ändrar resultatet har du ett spår i certifikatverifieringen — inte bevis på att proxyvägen reparerades.

Använd det ursprungliga felet för att avgöra nästa utredning. Ett återkallat certifikat, otillgänglig återkallelseinformation och ett orelaterat kedjefel är olika fynd. För otillgänglig statusinformation, spåra verifierarens hämtningsväg och proxyautentisering under det Windows-konto som kör Cargo, med dess faktiska TLS-backend.

Identifiera också den misslyckade nedladdningen. Cargos HTTP-överföringar och ett separat Git-anrop kan ha olika konfiguration. Ett lyckat nytt försök på en väg säger inget om den andras certifikatpolicy.

Håll obligatorisk verifiering aktiverad medan du reparerar hämtning och förtroende. Om en organisation avsiktligt stänger av återkallelsekontrollen ska det registreras som ett policybeslut, inte som en allmän inställning för proxykompatibilitet.

Relaterade artiklar