SSL-sertifikatfeil etter omdirigeringer med en tilpasset CA-pakke

Selskapets CA-fil retter den første URL-en, deretter feiler en omdirigering verifiseringen. Kontroller om det tilpassede CA-alternativet erstattet klientens tidligere tillitsinndata i stedet for å legge til dem.

Denne oppførselen avhenger av TLS-backenden og alternativet. En fil som bare inneholder bedrifts-CA-en, kan la klienten stå uten andre nødvendige myndigheter.

1. Følg hver motpart. Den første verten kan bli avlyttet under bedriftsutstederen. En senere vert kan bruke en omgåelse, en annen inspeksjonsrute eller en offentlig utstedt kjede.
2. Registrer inndataene til klienten som feiler. Behold det forespurte vertsnavnet, omdirigeringsmålet, mottatt utsteder, verifiseringsresultat og valgt tillitskonfigurasjon. En fungerende nettleser kan bruke et annet rotlager.
3. Kontroller utvalgsreglene til backenden. curl-bygg kan bruke innebygd verifisering eller filbaserte røtter, og eksplisitte CA-alternativer kan endre dette valget. En oppskrift for den kjørbare filen konfigurerer ikke et Python-miljø eller en JVM.

Bruk en vedlikeholdt pakke eller en støttet ordning for tillitslager som inneholder de offentlige og private myndighetene applikasjonen skal stole på. Ikke legg til en privat nøkkel for en CA, og ikke forfrem hvert feilende bladsertifikat til en rot bare for å fjerne den neste feilen.

Lever tillitsmaterialet via distribusjonens støttede oppdateringsrute. Manuell utskifting av en leverandør-CA-pakke kan bli omgjort av dens neste oppdatering; hold eieren og vedlikeholdsprosessen eksplisitte slik at verifiseringen fortsetter gjennom hele forespørselsruten.