ຂໍ້ຜິດພາດໃບຢັ້ງຢືນເມື່ອໃຊ້ພຣັອກຊີ
ກ່ອນປ່ຽນການຕັ້ງຄ່າໃບຢັ້ງຢືນ ໃຫ້ຮູ້ວ່າການຢືນຢັນລົ້ມເຫຼວທີ່ TLS ຂອງພຣັອກຊີເອງ ຫຼືຂອງເວັບໄຊປາຍທາງ.
ກ່ອນປ່ຽນຊຸດ CA ໃຫ້ຫາວ່າການຈັບມື TLS ໃດລົ້ມເຫຼວ. ໃບຢັ້ງຢືນຂອງພຣັອກຊີ ແລະຂອງເວັບໄຊອາດຖືກກວດໃນການເຊື່ອມຕໍ່ຄົນລະຊຸດ.
| ພຣັອກຊີ ແລະປາຍທາງ | ການກວດ TLS |
|---|---|
| ພຣັອກຊີ HTTP ໄປຫາປາຍທາງ HTTPS | ຫຼັງ CONNECT ຢືນຢັນໃບຢັ້ງຢືນປາຍທາງຜ່ານອຸໂມງ. |
| ພຣັອກຊີ HTTPS ໄປຫາປາຍທາງ HTTPS | ຢືນຢັນ TLS ໄປຫາພຣັອກຊີກ່ອນ; ຫຼັງອຸໂມງເປີດ ຢືນຢັນເຊດຊັນ TLS ແຍກຕ່າງຫາປາຍທາງ. |
ໃຊ້ບັນທຶກຕິດຕາມແບບລະອຽດເພື່ອຮູ້ຊື່ໂຮສທີ່ຮ້ອງຂໍ ແລະການຈັບມືຫຼ້າສຸດທີ່ສຳເລັດ. ຂໍ້ຜິດພາດໃບຢັ້ງຢືນພຣັອກຊີ HTTPS ອາດເກີດກ່ອນຕິດຕໍ່ເວັບໄຊ. ກວດຊື່ທີ່ຕັ້ງໃຈໃຊ້ກັບການເຊື່ອມຕໍ່ນັ້ນ ໄລຍະມີຜົນຂອງໃບຢັ້ງຢືນ ໂມງໃນເຄື່ອງ ຕ່ອງໂສ້ທີ່ຄາດໄວ້ ແລະຄັງຄວາມເຊື່ອຖືທີ່ອະນຸມັດ. ລວມການດັກຮັບ TLS ທີ່ຕັ້ງຄ່າໄວ້ໂດຍຕັ້ງໃຈ ຫຼືໃບຢັ້ງຢືນຮາກທີ່ເພີ່ມເຂົ້າມາໃນການກວດສອບດ້ວຍ.
curl ມີຕົວເລືອກ CA ແຍກກັນສຳລັບການເຊື່ອມຕໍ່ທັງສອງ:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert ລະບຸຖານຄວາມເຊື່ອຖືສຳລັບພຣັອກຊີ; --cacert ສຳລັບປາຍທາງ. ປ່ຽນຈຸດເຊື່ອມຕໍ່ ແລະໄຟລ໌ໃນຕົວຢ່າງເປັນຄ່າຕາມການຈັດວາງຄວາມເຊື່ອຖືທີ່ຕ້ອງການ. ຖ້າຄວາມເຊື່ອຖືຂອງລະບົບພຽງພໍແລ້ວ ບໍ່ຈຳເປັນຕ້ອງມີຊຸດສ່ວນຕົວ.
ການແທນຊື່ໂຮສດ້ວຍ IP ໃດໜຶ່ງຕາມໃຈຈະປ່ຽນການຈັບຄູ່ໃບຢັ້ງຢືນ. ການຂ້າມການຢືນຢັນອາດເຊື່ອງບັນຫາໂດຍບໍ່ຢືນຢັນຕົວຕົນອີກຝ່າຍ. ສຳລັບພຣັອກຊີທີ່ບໍ່ຮູ້ຈັກ ການຂໍໃຫ້ຕິດຕັ້ງ CA ຮາກຂອງມັນບໍ່ແມ່ນເຫດຜົນພຽງພໍທີ່ຈະເຊື່ອຖືມັນ.
ການເຊື່ອມຕໍ່ພອດຖືກປະຕິເສດ ຫຼື CONNECT ຖືກປະຕິເສດເປັນບັນຫາໃນຂັ້ນກ່ອນໜ້າ; ການປ່ຽນໃບຢັ້ງຢືນແກ້ບໍ່ໄດ້. ໃນທາງກັບກັນ ຫຼັງຢືນຢັນ TLS ປາຍທາງແລ້ວ ຂໍ້ຜິດພາດ HTTP ຂອງເວັບໄຊແມ່ນເລື່ອງຂອງຄຳຕອບທີ່ໄດ້ຮັບ ບໍ່ແມ່ນປັບ CA ອີກຮອບ.