ข้อผิดพลาด curl 77: ตำแหน่งตรวจสอบใบรับรองระหว่างติดตั้ง VPN
ข้อผิดพลาด 77 คือความล้มเหลวของอินพุต CA ภายในเครื่อง ไม่ใช่ใบรับรองเซิร์ฟเวอร์ที่แย่ ค้นหาไฟล์ความเชื่อถือที่ curl อ่าน แก้ไข และตรวจสอบสคริปต์ก่อนรัน
คุณวางคำสั่งติดตั้งบรรทัดเดียวจากบทช่วยสอน กด Enter แล้วได้ curl: (77). ข้อความกล่าวถึงตำแหน่งตรวจสอบใบรับรอง จึงเป็นธรรมดาที่จะคิดว่าใบรับรองของผู้ให้บริการ VPN เสียและไปหาธงที่ข้ามการตรวจสอบ การตีความนั้นผิด และการทำตามนั้นเปลี่ยนปัญหไฟล์ภายในเครื่องให้เป็นการตัดสินใจด้านความปลอดภัย ย้อนกลับไปตั้งแต่ต้นกันดีกว่า
ขั้นที่ 1: อ่านว่าตัวเลขนี้หมายถึงอะไร
ข้อผิดพลาด 77 เกี่ยวกับอินพุต CA ภายในเครื่อง: curl อ่านหรือโหลดวัสดุใบรับรองที่บอกให้เชื่อถือไม่ได้ ข้อผิดพลาด 60 คือกรณีของอีกฝ่าย เมื่อ ห่วงโซ่ของเซิร์ฟเวอร์ไม่ผ่านการตรวจสอบ. ทั้งสองปรากฏเคียงกันในบทช่วยสอนแต่มีความหมายตรงกันข้าม
ถ้าเอาต์พุตของคุณบอก 77 เซิร์ฟเวอร์ไม่เคยเป็นปัญหา ไคลเอนต์เปิดไฟล์ที่ต้องการใช้ตรวจสอบไม่ได้ และนี่คือปัญหาเส้นทาง สิทธิ์ หรือการแพ็กเกจบนเครื่องของคุณ
ขั้นที่ 2: อ่านคำสั่งที่คุณคัดลอกมา
คำสั่งที่คัดลอกมาซ่อนอักขระไว้ ตัวพิมพ์เล็ก -l คือ --list-only ซึ่งใช้กับการแสดงรายการโปรโตคอล ตัวพิมพ์ใหญ่ -L คือ --location ซึ่งติดตามการเปลี่ยนเส้นทาง HTTP ทั้งสองไม่ใช่การสะกดทางเลือก และบทช่วยสอนที่เขียนอันหนึ่งแต่บรรยายอีกอันจะพาคนไปตามเส้นทางการเปลี่ยนเส้นทางที่ไม่เคยตั้งใจไว้
การตามการเปลี่ยนเส้นทางไม่ได้ซ่อมแซมเส้นทางของที่เก็บความเชื่อถือ และไม่ได้พิสูจน์ว่าโฮสต์สุดท้ายคือผู้เผยแพร่ที่คุณต้องการ ถ้าคำสั่งมาจากโพสต์ในฟอรัม ให้พิมพ์ใหม่จากคำแนะนำของโปรเจกต์เองแทนที่จะเชื่อสิ่งที่วางมา
ขั้นที่ 3: หาว่าการบิลด์นั้นใช้อินพุต CA ตัวใด
เริ่มจากการระบุไบนารี เพราะคำตอบขึ้นอยู่กับวิธีคอมไพล์:
curl --versionบันทึกเวอร์ชันและ TLS backend การบิลด์ที่ใช้ที่เก็บความเชื่อถือแบบเนทีฟจะอ่านที่เก็บของระบบผ่านไลบรารี TLS ส่วนการบิลด์ที่ชี้ไปยังบันเดิลจะอ่านไฟล์ --cacert ที่ระบุชัดเจน การตั้งค่า CURL_CA_BUNDLE หรือ shell wrapper สามารถเขียนทับได้ทั้งสองแบบ ดังนั้นการติดตั้งจากแพ็กเกจอาจไม่แตะไฟล์ที่ล้มเหลวจริง
สำหรับที่เก็บแบบไฟล์ ให้ตรวจสามอย่างตามลำดับ: เส้นทางมีอยู่หรือไม่ บัญชีที่เรียกคำสั่งอ่านได้หรือไม่ และมีวัสดุ CA ที่คุณคาดหวังหรือไม่ บันเดิลที่มีสิทธิ์ผิดจะล้มเหลวเหมือนกับอันที่หายไป และทั้งสองล้มเหลวก่อนการสนทนาผ่านเครือข่ายเกี่ยวกับเซิร์ฟเวอร์จะเกิดขึ้น
ขั้นที่ 4: ซ่อมอินพุต ไม่ใช่การตรวจสอบ
คืนค่าการกำหนดค่าความเชื่อถือที่รองรับผ่านเจ้าของ: แพ็กเกจดิสทริบิวชัน การจัดการคอนฟิกของคุณ หรือตัวแปรสภาพแวดล้อมที่บันทึกไว้ เป้าหมายคืออินพุต CA ที่อ่านได้และถูกต้องสำหรับไบนารีนั้น
อย่าเปลี่ยน URL เป็น HTTP อย่าเพิ่ม --insecure และอย่าเชื่อถือใบรับรองที่คัดลอกจากดาวน์โหลดที่ไม่ชัดเจน การเปลี่ยนแปลงแต่ละอย่างนั้นเปลี่ยนสิ่งที่คุณยอมรับแทนที่จะซ่อมสิ่งที่ curl อ่านไม่ได้ และการเปลี่ยนแปลงมักมีอายุยืนกว่าอุบัติการณ์
เอกสารอ้างอิงสำหรับตัวเลขเหล่านี้คือ แคตตาล็อกข้อผิดพลาดของ curl และสั้นพอที่จะอ่านอย่างละเอียดสักครั้ง
ขั้นที่ 5: ดาวน์โหลด ดู แล้วจึงรัน
ดาวน์โหลดตัวติดตั้งลงไฟล์แทนที่จะส่งผ่านท่อไปยัง shell ในคำสั่งเดียวกัน การเปลี่ยนแปลงเดียวนี้แยกการถ่ายโอนที่คุณตรวจสอบได้ออกจากโค้ดที่รันด้วยสิทธิ์ของคุณ
curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.shตรวจสอบว่าการตอบกลับเป็นสคริปต์ที่คุณคาดหวัง ไม่ใช่หน้าแสดงข้อผิดพลาด HTML ประกาศการเปลี่ยนเส้นทาง หรือไฟล์ว่าง ถ้าผู้เผยแพร่มีเช็กซัมหรือลายเซ็น ให้ตรวจสอบผ่านกระบวนการเผยแพร่ที่บันทึกไว้ ไม่ใช่ค่าที่อ้างในเธรดฟอรัมเดียวกัน
จำไว้ว่า HTTPS ทำอะไรและไม่ได้ทำอะไร มันยืนยันการขนส่งถึงโฮสต์ที่คุณติดต่อ ไม่ได้ตรวจเนื้อหาของสคริปต์ และไม่ได้บอกว่าผู้เผยแพร่เชื่อถือได้หรือไม่
ขั้นที่ 6: แยกขั้นตอนการติดตั้งออกจากกัน
การดาวน์โหลดไฟล์ การติดตั้งไคลเอนต์ การกำหนดค่าอุโมงค์ และการตรวจสอบเส้นทางเป็นสี่การดำเนินการที่มีรูปแบบล้มเหลวต่างกัน การทำทีละอย่างหมายความว่าข้อผิดพลาดที่เกิดภายหลังในลำดับมีสาเหตุชัดเจนหนึ่งอย่างแทนที่จะเป็นสี่ตัวเลือก
ถ้าติดตั้งสำเร็จและอุโมงค์ขึ้นมา ให้ตรวจสอบเส้นทางและปลายทางจริงหนึ่งแห่งก่อนปิดตั๋ว ข้อผิดพลาดของ curl ได้รับการแก้ไขเมื่อ curl -I https://example.invalid ธรรมดาทำงานได้อีกครั้ง ไม่ใช่เมื่อตัวติดตั้งเลิกบ่น