SoftEther ServerCertSet: นำเข้าเชนที่ต่ออายุแล้วด้วย vpncmd

Certbot รายงานการต่ออายุสำเร็จ ไฟล์บนดิสก์มีวันที่ใหม่ และไคลเอนต์ยังพบตัวตนเก่า SoftEther เก็บใบรับรอง SSL ของเซิร์ฟเวอร์ไว้ในคอนฟิกูเรชันระดับเซิร์ฟเวอร์ของตัวเอง ดังนั้นไฟล์ใหม่บนดิสก์ไม่เปลี่ยนอะไรจนกว่าใบรับรองปลายทางและกุญแจจะถูกนำเข้า ลำดับด้านล่างครอบคลุมการนำเข้าด้วยมือหนึ่งครั้ง ตัวห่อที่ทำงานหลังการต่ออายุแต่ละครั้ง และการตรวจสอบที่อ่านสิ่งที่ตัวรับฟังนำเสนอจริง แต่ละขั้นตอนทิ้งหลักฐานที่คุณเปรียบเทียบได้หลังการต่ออายุครั้งถัดไป

ไฟล์ที่ต่ออายุแล้วไม่เปลี่ยนตัวตนของเซิร์ฟเวอร์

การออกใบรับรองและการปรับใช้เป็นเหตุการณ์แยกกันด้วยรูปแบบความล้มเหลวที่แยกกัน ไคลเอนต์ ACME เขียนไฟล์ลงไดเรกทอรี lineages และบันทึกความสำเร็จ ส่วน SoftEther ยังคงใช้ใบรับรองที่โหลดเข้าคอนฟิกูเรชันครั้งล่าสุด สถานะออกเป็นศูนย์จึงอธิบายไฟล์ ไม่ใช่บริการ และทั้งสองอาจไม่ตรงกันตราบใดที่ไม่มีใครดู ถือว่าการนำเข้าเป็นขั้นตอนการปรับใช้และการต่ออายุเป็นอินพุตของมัน

ความแตกต่างนี้อธิบายความล้มเหลวครึ่งเดียวที่สับสนด้วย: ใบรับรองเก่ายังทำงานจนหมดอายุ จึงดูเหมือนไม่มีอะไรเสียในตอนแรก เมื่อหมดอายุ ไคลเอนต์ทั้งหมดล้มเหลวพร้อมกัน ซึ่งดูเหมือนการหยุดให้บริการไม่ใช่ขั้นตอนการปรับใช้ที่พลาดไป การตรวจสอบตัวตนที่นำเสนอหลังการต่ออายุแต่ละครั้งเปลี่ยนความประหลาดใจนั้นให้เป็นการสังเกตตามปกติ

เลือกความท้าทายที่เหมาะกับตัวรับฟัง

ใบรับรองต้องระบุชื่อโฮสต์ที่ไคลเอนต์ตรวจสอบ ดังนั้นใช้ชื่อ DNS สาธารณะแทนป้ายภายในหรือที่อยู่ HTTP-01 ต้องให้ความท้าทายได้รับคำตอบที่พอร์ต 80 ชั่วขณะ ซึ่งเป็นตัวรับฟังชั่วคราวและไม่ใช่เหตุผลให้ย้ายพอร์ตของ SoftEther เอง DNS-01 พิสูจน์การควบคุมผ่านเรกคอร์ดและไม่ต้องใช้ HTTP ขาเข้าเลย

การต่ออายุแบบไม่มีคนดูแลหมายถึงการรวม DNS อัตโนมัติด้วยข้อมูลรับรองที่จำกัดเฉพาะโซนเดียว ไม่ใช่เรกคอร์ด TXT ที่พิมพ์ด้วยมือทุกสองเดือน ไวลด์การ์ดเปลี่ยนชนิดของความท้าทาย ไม่ใช่ความจำเป็นของการทำงานอัตโนมัตินั้น ตัดสินใจเรื่องนี้ก่อนมีใบรับรองใบแรก เพราะการเปลี่ยนชนิดความท้าทายภายหลังหมายถึงการแตะคอนฟิกูเรชันไคลเอนต์และไฟร์วอลล์พร้อมกัน

เก็บอาร์ติแฟกต์ให้เป็นระเบียบระหว่างอยู่ที่นี่ ใบรับรองปลายทางและตัวกลางมาเป็นไฟล์แยกและเป็นไฟล์เชนรวมไฟล์เดียว กุญแจส่วนตัวแยกอีกครั้ง และการนำเข้าต้องการเชนพร้อมกุญแจที่เข้าคู่กัน ไม่ใช่ใบรับรองสาธารณะเพียงอย่างเดียว

นำเข้าเชนที่ระดับเซิร์ฟเวอร์

สำรองคอนฟิกูเรชันเซิร์ฟเวอร์และยืนยันว่ายังเข้าถึงอินเทอร์เฟซการจัดการได้ก่อนแตะใบรับรอง เชื่อมต่อในฐานะผู้ดูแลเซิร์ฟเวอร์ไม่ใช่ผู้ดูแล Virtual Hub เพราะใบรับรองเป็นของออบเจกต์เซิร์ฟเวอร์ จากนั้นโหลดเชนและกุญแจด้วยพาธแบบสัมบูรณ์ จากไฟล์ที่บัญชีซึ่งเรียกใช้คำสั่งอ่านได้ สังเกตว่าพาธเป็นแบบสัมบูรณ์เพราะคำสั่งแก้ไขพาธเหล่านั้นจากไดเรกทอรีทำงานของโพรเซสที่เรียกใช้ vpncmd:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

อ่านเอาต์พุตของคำสั่งแทนการถือว่าสำเร็จ แล้วอ่านเชนกลับแทนการเชื่อถือไฟล์ที่คุณให้ไป ขอบเขตระหว่างบิลด์ที่นำเข้าชุด PEM ทั้งหมดกับบิลด์ที่เอาเพียงใบรับรองใบแรกไม่ได้ถูกบันทึกไว้ที่เดียว การตรวจสอบจึงเป็นสิ่งที่ตัดสินให้บิลด์ที่อยู่ตรงหน้าคุณ นับใบรับรองที่ตัวรับฟังนำเสนอ ใบรับรองปลายทางที่ไม่มีตัวกลางคือลายเซ็นของผู้นำเข้าที่ใช้เพียงบล็อกแรก

เก็บกุญแจที่นำเข้าให้อ่านได้เฉพาะบัญชีที่เรียกใช้เซิร์ฟเวอร์ และเก็บรหัสผ่านการจัดการไว้นอกประวัติเชลล์ สำหรับการนำเข้าครั้งแรกนี้ ให้พิมพ์รหัสผ่านที่พรอมต์แทนการส่งเป็นอาร์กิวเมนต์ของคำสั่ง นิสัยสองอย่างนี้ไม่เสียค่าใช้จ่ายและขจัดวิธีที่พบบ่อยที่สุดที่การปรับใช้ใบรับรองรั่วไหลสิ่งที่ควรปกป้อง ทำสิ่งนี้ก่อนการนำเข้าครั้งแรก ไม่ใช่หลัง

เชื่อมการปรับใช้ ไม่ใช่การต่ออายุ

เมื่อการนำเข้าด้วยมือทำงานได้ ให้นำขั้นตอนเหล่านั้นใส่ในตัวห่อเล็ก ๆ และเรียกจากไคลเอนต์ ACME หลังการต่ออายุสำเร็จ Certbot ตั้งค่า RENEWED_LINEAGE และ RENEWED_DOMAINS สำหรับฮุก ตัวห่อจึงทำงานกับใบรับรองเดียวบนเครื่องที่จัดการหลายใบได้ กรองตาม lineage แทนการตอบสนองต่อทุกการต่ออายุบนโฮสต์ ตัวห่อเป็นโค้ดปรับใช้ที่ทำงานด้วยสิทธิ์ของเซิร์ฟเวอร์ จึงตรวจทานเหมือนสคริปต์อื่นในตำแหน่งนั้น

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

ฮุกที่ทำงานโดยไม่มีคนดูแลต้องการที่เก็บข้อมูลรับรองที่ได้รับการปกป้องของตัวเองและสัญญาณความล้มเหลวที่ไปถึงคน หากการออกใบรับรองสำเร็จแต่การนำเข้าล้มเหลว ให้ลองนำเข้าอีกครั้งแทนการขอใบรับรองใหม่ เพราะคำขอที่สองซ่อนข้อบกพร่องของการปรับใช้ไว้หลังไฟล์ใหม่ เอกสารการต่ออายุของ Certbot ระบุชัดว่าการรันที่ไม่ปรับปรุงสิ่งใดเป็นผลลัพธ์ปกติ ฮุกจึงเป็นสิ่งที่แยกสองกรณีนั้น

เปรียบเทียบเชนที่นำเสนอกับไฟล์

อ่านตัวรับฟัง ไม่ใช่ดิสก์ เชื่อมต่อพอร์ตที่หันหน้าไปทางไคลเอนต์ด้วยชื่อเซิร์ฟเวอร์ที่ไคลเอนต์ใช้ แล้วเปรียบเทียบลายนิ้วมือและเชนที่ส่งมอบกับ lineage ที่ฮุกติดตั้ง สองคำสั่งครอบคลุมเรื่องนี้ และคำสั่งแรกยังแสดงว่าตัวกลางมาถึงหรือไม่:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

จากนั้นสร้างการเชื่อมต่อไคลเอนต์ใหม่ เพราะเซสชันที่สร้างก่อนการนำเข้าได้รับการพิสูจน์ตัวตนกับตัวตนก่อนหน้าและไม่ได้พิสูจน์สิ่งใดเกี่ยวกับตัวตนใหม่ หาก ไคลเอนต์ปักหมุดใบรับรองปลายทางเก่า พวกเขาต้องการการอัปเดตที่ประสานกันแม้เมื่อเชนสาธารณะยังใช้ได้ และงานนั้นอยู่ในรันบุ๊กเดียวกับการต่ออายุ พร็อกซีย้อนกลับหน้าเซอร์วิสอาจนำเสนอใบรับรองที่ดีในขณะที่ตัวรับฟัง VPN ยังถือของเก่า ดังนั้นการตรวจสอบต้องระบุพอร์ตที่ไคลเอนต์เข้าถึงจริง บันทึกลายนิ้วมือข้างวันที่ต่ออายุ เพื่อให้การเปรียบเทียบครั้งถัดไปเป็นการตรวจสอบไม่ใช่การกระทำจากความจำ