SSL sertifikato klaidos po peradresavimų su pasirinktiniu CA rinkiniu
Patikrinkite, ar aiškiai pasirinktas CA failas turi visą pasitikėjimo medžiagą, kurios reikia faktiniam užklausos keliui, įskaitant peradresuotus hostus.
Įmonės CA failas sutvarko pirmąjį URL, tada peradresavimas nepraeina patikros. Patikrinkite, ar pasirinktinė CA parinktis pakeitė ankstesnį kliento pasitikėjimo įvestį, o ne ją papildė.
Tokia elgsena priklauso nuo TLS backend ir parinkties. Failas, kuriame yra tik įmonės CA, gali palikti klientą be kitų reikalingų institucijų.
- Sekite kiekvieną partnerį. Pirmasis hostas gali būti perimtas pagal įmonės išdavėją. Vėlesnis hostas gali naudoti apėjimą, kitą tikrinimo kelią ar viešai išduotą grandinę.
- Užfiksuokite nepavykusio kliento įvestis. Išsaugokite prašomą hosto vardą, peradresavimo tikslą, gautą išdavėją, patikros rezultatą ir pasirinktą pasitikėjimo konfigūraciją. Veikianti naršyklė gali naudoti kitą šaknų saugyklą.
- Patikrinkite backend pasirinkimo taisykles. curl kompiliavimo variantai gali naudoti vietinę patikrą arba failais pagrįstas šaknis, o aiškios CA parinktys gali pakeisti tą pasirinkimą. To vykdomojo failo receptas nesukonfigūruoja Python aplinkos ar JVM.
Naudokite prižiūrimą rinkinį arba palaikomą pasitikėjimo saugyklos išdėstymą, kuriame yra viešosios ir privačios institucijos, kuriomis programa turėtų pasitikėti. Nepridėkite CA privataus rakto ir nekelkite kiekvieno nepavykusio lapo sertifikato į šaknį vien tam, kad pašalintumėte kitą klaidą.
Pristatykite pasitikėjimo medžiagą palaikomu diegimo atnaujinimo keliu. Rankinis tiekėjo CA paketo pakeitimas gali būti atšauktas kitu jo atnaujinimu; aiškiai nurodykite savininką ir priežiūros procesą, kad patikra tęstųsi visame užklausos maršrute.