SSL-sertifikaatfoute ná herleidings met 'n pasgemaakte CA-bundel
Kontroleer of 'n eksplisiet gekose CA-lêer al die vertrouemateriaal bevat wat die werklike versoekpad nodig het, insluitend herleide gashere.
Die maatskappy se CA-lêer regstel die eerste URL, dan misluk 'n herleiding se verifikasie. Kyk of die pasgemaakte CA-opsie die kliënt se vorige vertroue-invoer vervang het eerder as om daarby te voeg.
Daardie gedrag hang af van die TLS-agterkant en die opsie. 'n Lêer wat net die korporatiewe CA bevat, kan die kliënt sonder ander owerhede laat wat dit nodig het.
- Volg elke eweknie. Die eerste gasheer kan onder die korporatiewe uitreiker onderskep word. 'n Latere gasheer kan 'n omleiding, 'n ander inspeksiepad of 'n publiek uitgereikte ketting gebruik.
- Teken die falende kliënt se insette aan. Hou die versoekte gasheernaam, herleidingsteiken, ontvangde uitreiker, verifikasie-uitslag en gekose vertrouekonfigurasie. 'n Werkende blaaier gebruik dalk 'n ander wortelstoor.
- Kontroleer die agterkant se keelreëls. curl-boude kan inheemse verifikasie of lêergebaseerde wortels gebruik, en eksplisiete CA-opsies kan daardie keuse verander. 'n Resep vir daardie uitvoerbare lêer stel nie 'n Python-omgewing of JVM op nie.
Gebruik 'n onderhoude bundel of ondersteunde vertrouestoor-reëling wat die openbare en private owerhede bevat wat die toepassing bedoel is om te vertrou. Moet nie 'n CA se private sleutel byvoeg of elke falende bladsertifikaat tot 'n wortel bevorder net om die volgende fout uit te wis nie.
Lewer die vertrouemateriaal deur die ontplooiing se ondersteunde opdateringspad. Om 'n verskaffer se CA-pakket handmatig te vervang, kan deur die volgende opdatering ongedaan gemaak word; hou die eienaar en onderhoudsproses eksplisiet sodat verifikasie oor die volle versoekroete voortduur.