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 det.

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 inspeksjonsbane 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 back-endens utvalgsregler. 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 CAs private nøkkel, og ikke forfrem hvert feilende bladsertifikat til en rot bare for å fjerne den neste feilen.

Lever tillitsmaterialet via distribusjonens støttede oppdateringsbane. Manuell erstatning av en leverandørs CA-pakke kan bli angret av dens neste oppdatering; hold eieren og vedlikeholdsprosessen eksplisitt slik at verifiseringen fortsetter gjennom hele forespørselsruten.