Gabime certifikate SSL pas ridrejtimeve me një paketë CA të personalizuar
Kontrolloni nëse skedari CA i zgjedhur në mënyrë eksplicite përmban të gjithë materialin e besimit që kërkon shtegu real i kërkesës, përfshirë hostet e ridrejtuara.
Skedari CA i kompanisë rregullon URL-në e parë, pastaj një ridrejtim dështon verifikimin. Kontrolloni nëse opsioni i personalizuar CA zëvendësoi hyrjen e mëparshme të besimit të klientit në vend që t'i shtohej asaj.
Kjo sjellje varet nga backend-i TLS dhe opsioni. Një skedar që përmban vetëm CA korporative mund ta lërë klientin pa autoritete të tjera që i nevojiten.
- Ndiqni çdo palë. Host-i i parë mund të përgjohet nën lëshuesin korporativ. Një host i mëvonshëm mund të përdorë një anashkalim, një shteg tjetër inspektimi ose një zinxhir të lëshuar publikisht.
- Regjistroni hyrjet e klientit që dështon. Mbani emrin e host-it të kërkuar, objektivin e ridrejtimit, lëshuesin e marrë, rezultatin e verifikimit dhe konfigurimin e besimit të zgjedhur. Një shfletues funksional mund të përdorë një depo tjetër rrënjësh.
- Kontrolloni rregullat e zgjedhjes së backend-it. Ndërtimet e curl mund të përdorin verifikim vendas ose rrënjë të bazuara në skedarë, dhe opsionet eksplicite CA mund ta ndryshojnë atë zgjedhje. Një recetë për atë ekzekutues nuk konfiguron një mjedis Python ose JVM.
Përdorni një paketë të mirëmbajtur ose një rregullim të mbështetur të depos së besimit që përmban autoritetet publike dhe private që aplikacioni duhet të besojë. Mos shtoni çelësin privat të një CA dhe mos ngrini çdo certifikatë fletë që dështon në rrënjë vetëm për të hequr gabimin tjetër.
Dorëzoni materialin e besimit përmes shtegut të mbështetur të përditësimit të vendosjes. Zëvendësimi manual i një pakete CA të furnizuesit mund të zhbëhet nga përditësimi i tij i radhës; mbani pronarin dhe procesin e mirëmbajtjes eksplicit që verifikimi të vazhdojë përgjatë gjithë rrugës së kërkesës.