Inaayos ng CA file ng kumpanya ang unang URL, pagkatapos ay nabigo ang isang redirect sa pagpapatunay. Suriin kung pinalitan ng custom na CA option ang dating input ng pagtitiwala ng kliyente sa halip na idagdag ito.

Nakadepende ang gawi na iyon sa TLS backend at sa opsyon. Ang file na naglalaman lamang ng corporate CA ay maaaring mag-iwan sa kliyente na walang ibang mga awtoridad na kailangan nito.

  1. Sundan ang bawat kapares. Ang unang host ay maaaring harangin sa ilalim ng corporate issuer. Ang susunod na host ay maaaring gumamit ng bypass, ibang landas ng inspeksyon o pampublikong inisyu na chain.
  2. Itala ang mga input ng nabigong kliyente. Itago ang hiniling na hostname, target ng redirect, natanggap na issuer, resulta ng pagpapatunay at piniling configuration ng pagtitiwala. Ang gumaganang browser ay maaaring gumamit ng ibang root store.
  3. Suriin ang mga tuntunin sa pagpili ng backend. Ang mga build ng curl ay maaaring gumamit ng native na pagpapatunay o mga root na nakabatay sa file, at ang tahasang CA option ay maaaring magbago ng pagpiling iyon. Ang recipe para sa executable na iyon ay hindi nagko-configure ng Python environment o JVM.

Gumamit ng maintained na bundle o sinusuportahang kaayusan ng trust store na naglalaman ng pampubliko at pribadong awtoridad na dapat pagtiwalaan ng application. Huwag idagdag ang private key ng isang CA at huwag itaas ang bawat nabigong leaf certificate sa root para lang alisin ang susunod na error.

Ihatid ang materyal ng pagtitiwala sa sinusuportahang landas ng pag-update ng deployment. Ang manu-manong pagpapalit ng CA package ng vendor ay maaaring bawiin ng susunod nitong update; panatilihing tahasan ang may-ari at proseso ng pagpapanatili upang magpatuloy ang pagpapatunay sa buong ruta ng kahilingan.

Kaugnay na mga artikulo