Virksomhedens CA-fil retter den første URL, derefter fejler en omdirigering verifikationen. Kontrollér, om den tilpassede CA-indstilling erstattede klientens tidligere tillidsinput i stedet for at føje til det.

Denne adfærd afhænger af TLS-backenden og indstillingen. En fil, der kun indeholder virksomhedens CA, kan efterlade klienten uden andre nødvendige myndigheder.

  1. Følg hver modpart. Den første vært kan blive opsnappet under virksomhedens udsteder. En senere vært kan bruge en omvej, en anden inspektionssti eller en offentligt udstedt kæde.
  2. Registrér den fejlende klients input. Behold det anmodede værtsnavn, omdirigeringsmålet, den modtagne udsteder, verifikationsresultatet og den valgte tillidskonfiguration. En fungerende browser kan bruge et andet rodbibliotek.
  3. Kontrollér backendens valgregler. curl-byg kan bruge indbygget verifikation eller filbaserede rødder, og eksplicitte CA-indstillinger kan ændre dette valg. En opskrift til den eksekverbare fil konfigurerer ikke et Python-miljø eller en JVM.

Brug en vedligeholdt pakke eller en understøttet tillidslagringsordning med de offentlige og private myndigheder, som applikationen skal stole på. Tilføj ikke en CAs private nøgle, og forfrem ikke hvert fejlende bladcertifikat til en rod blot for at fjerne den næste fejl.

Lever tillidsmaterialet via implementeringens understøttede opdateringssti. Manuel udskiftning af en leverandørs CA-pakke kan blive omgjort af dens næste opdatering; hold ejeren og vedligeholdelsesprocessen eksplicit, så verifikationen fortsætter gennem hele anmodningsruten.

Relaterede artikler