ໃຜສົ່ງໃບຢັ້ງຢືນລູກຄ້າຜ່ານພຣອກຊີ?
ແຍກຂໍ້ມູນ mTLS ຂອງປາຍທາງອອກຈາກຂໍ້ມູນຂອງພຣອກຊີ ແລະ ຈາກໃບຢັ້ງຢືນທີ່ Apache ໃຊ້ເມື່ອສ້າງເຊສຊັນ TLS ຂຶ້ນຂອງຕົນເອງ.
ໃນ HTTPS ຜ່ານ CONNECT ທົ່ວໄປ, ແອັບພລິເຄຊັນຈະສົ່ງໃບຢັ້ງຢືນລູກຄ້າຂອງເວັບໄຊທ໌ໃນລະຫວ່າງການຈັບມື TLS ປາຍທາງຂອງຕົນເອງ. ພຣອກຊີພຽງແຕ່ສົ່ງຕໍ່ໄບຕ໌; ມັນບໍ່ໄດ້ກາຍເປັນລູກຄ້າ TLS ຂອງເວັບໄຊທ໌ໂດຍອັດຕະໂນມັດ.
| ຂໍ້ມູນຢືນຢັນ | ເຈົ້າຂອງ/ການເຊື່ອມຕໍ່ |
|---|---|
| ຊື່ຜູ້ໃຊ້/ລະຫັດຜ່ານຂອງພຣອກຊີ | ການເຂົ້າເຖິງພຣອກຊີຂອງລູກຄ້າ. |
| ໃບຢັ້ງຢືນລູກຄ້າ ແລະ ກະແຈສ່ວນຕົວຂອງເວັບໄຊທ໌ | ເຊສຊັນ TLS ຂອງແອັບພລິເຄຊັນກັບປາຍທາງ. |
| ໃບຢັ້ງຢືນລູກຄ້າຂຶ້ນເທິງຂອງເຊີບເວີພຣອກຊີ | ເຊສຊັນ TLS ທີ່ພຣອກຊີເລີ່ມດ້ວຍຕົນເອງ. |
ບົດບາດເຫຼົ່ານີ້ສາມາດຢູ່ຮ່ວມກັນໄດ້. ການອັບໂຫຼດກະແຈສ່ວນຕົວຂອງເວັບໄຊທ໌ໄປຍັງພຣອກຊີອຸໂມງທຳມະດາບໍ່ຈຳເປັນເພື່ອໃຫ້ mTLS ປາຍທາງເຮັດວຽກ. ຫຼັງຈາກ ການສົ່ງຕໍ່ CONNECT, ໃຫ້ໃຊ້ການຕັ້ງຄ່າໃບຢັ້ງຢືນລູກຄ້າປາຍທາງປົກກະຕິຂອງແອັບພລິເຄຊັນ ແລະ ສືບຕໍ່ກວດສອບໃບຢັ້ງຢືນເຊີບເວີຂອງເວັບໄຊທ໌.
SSLProxyMachineCertificateFile ຂອງ Apache ສະໜອງຂໍ້ມູນຢືນຢັນເມື່ອ Apache ສ້າງເຊສຊັນ TLS ຂຶ້ນເທິງຂອງຕົນເອງ. ຄຳແນະນຳກ່ຽວກັບໄຟລ໌ນັ້ນບໍ່ໄດ້ພິສູດວ່າທຸກລູກຄ້າທີ່ໃຊ້ອຸໂມງສົ່ງຕໍ່ແບບບໍ່ໂປ່ງໃສຕ້ອງຕັ້ງຄ່າມັນ.
ການດັກຈັບ TLS ຢຸດເຊສຊັນຢູ່ຕົວກາງ ແລະ ປ່ຽນຄວາມເປັນເຈົ້າຂອງນີ້. ກຳນົດວ່າຕົວຕົນລູກຄ້າທີ່ຕ້ອງການສາມາດຜ່ານການຈັດລຽງນັ້ນໄດ້ຫຼືບໍ່ ແທນທີ່ຈະສົມມຸດວ່າການສຳເນົາໃບຢັ້ງຢືນຮັກສາການພິສູດຕົວຕົນແບບປາຍຕໍ່ປາຍ.
ເມື່ອລົ້ມເຫຼວ, ບັນທຶກວ່າຄຳຮ້ອງຢຸດຢູ່ການເຂົ້າສູ່ພຣອກຊີ, ຢູ່ TLS ປາຍທາງ ຫຼື ຢູ່ການແລກປ່ຽນຂອງແອັບພລິເຄຊັນຕໍ່ມາ. ໃຫ້ວາງຂໍ້ມູນຢືນຢັນໄວ້ໃນການເຊື່ອມຕໍ່ທີ່ຮ້ອງຂໍມັນຢ່າງແທ້ຈິງ.