# ใบรับรอง TLS ใน Webship: ACME CA ที่ฝังอยู่
ใบรับรอง TLS ทำงานสองอย่าง: ช่วยเข้ารหัสการเชื่อมต่อและบอกกับไคลเอนต์ว่ากำลังติดต่อกับตัวตนใด การเข้ารหัสอาจแข็งแกร่งในขณะที่การตัดสินใจเชื่อถืออาจผิดสำหรับผู้ชม นั่นเป็นเหตุผลที่การจัดการใบรับรองอัตโนมัติต้องเริ่มต้นด้วยคำถามหนึ่งข้อ: ใครต้องเชื่อถือเว็บไซต์นี้?
Webship 1.4.0 ทำการเลือกนั้นโดยอิสระสำหรับแต่ละไซต์ที่ตั้งค่าไว้ เว็บไซต์สาธารณะสามารถใช้ใบรับรอง ACME ที่เบราว์เซอร์เชื่อถือได้ บริการภายในสามารถใช้หน่วยงานออกใบรับรองส่วนตัวที่ฝังอยู่ของ Webship และไซต์ที่มี PKI อยู่แล้วสามารถเก็บไฟล์ใบรับรองที่ผู้ปฏิบัติการจัดการไว้ทั้งหมด สามารถแชร์หนึ่งกระบวนการ Webship ได้โดยไม่ต้องแชร์หนึ่งกุญแจส่วนตัวหรือขอบเขตความเชื่อถือหนึ่งเดียว
สี่โหมดใบรับรองอัตโนมัติ เลือกตามไซต์
ฟิลด์ certificate_mode เป็นของแต่ละรายการ [[sites]] มันไม่ใช่สวิตช์ทั่วทั้งระบบ
| โหมด | แหล่งที่เชื่อถือ | การปรับที่ดีที่สุด | เส้นทางการตรวจสอบ | | --- | --- | --- | --- | | ต่อ_ไซต์ | ร้านค้าความเชื่อถือของเบราว์เซอร์สาธารณะและระบบปฏิบัติการ | เว็บไซต์สาธารณะที่มีชื่อโฮสต์ตรงหนึ่ง | ACME สาธารณะพร้อม TLS-ALPN-01 | | กองเรือ | เว็บเบราว์สาธารณะและที่เก็บความเชื่อถือของระบบปฏิบัติการ | ชุดขนาดใหญ่ของชื่อระดับสามและสี่ภายใต้โดเมนที่จดทะเบียนอย่างชัดเจน | ACME สาธารณะพร้อม DNS-01 และชิ้นส่วนใบรับรองที่เสถียร | | ฝังตัว | ราก Webship ส่วนตัวที่ติดตั้งโดยผู้ปฏิบัติการ | บริการภายใน, อุปกรณ์ที่มีการจัดการ, กองยานส่วนตัว, และสภาพแวดล้อมการทดสอบ | การออกในกระบวนการ; ไม่มีการท้าทายนอก | | ร่วมกัน | ร้านค้าความเชื่อถือของเบราว์เซอร์สาธารณะและระบบปฏิบัติการ | การติดตั้งรุ่นเก่าที่ตั้งใจใช้กลุ่ม multi-SAN สาธารณะชุดเดียว | ACME สาธารณะกับ TLS-ALPN-01 |
ค่าเริ่มต้นคือ per_site มันสั่งใบรับรองสาธารณะหนึ่งใบสำหรับชื่อไซต์ที่ตรงกับชื่อของเว็บไซต์ โหมด Fleet เป็นตัวเลือกสาธารณะที่ปรับขนาดได้สำหรับหลายโดเมนย่อยลึก โหมดฝังตัวใช้ CA ส่วนตัวในกระบวนการของ Webship โหมดแชร์ยังคงใช้ได้เพื่อความเข้ากันได้ แต่ไม่ใช่ค่าเริ่มต้น
ใบรับรองและคีย์ที่สมบูรณ์ภายใต้ [sites.tls] จะมีความสำคัญมากกว่าการออกโดยอัตโนมัติสำหรับไซต์นั้นเสมอ
‘ACME CA ที่ฝังอยู่’ หมายถึงอะไร
ส่วนการกำหนดค่ามีชื่อว่า [acme_ca] แต่ CA ที่ฝังอยู่ไม่ใช่บริการ ACME สาธารณะหรือที่เข้าถึงผ่านเครือข่าย มันไม่เปิดเผยเอนด์พอยต์ไดเรกทอรี ไม่รับการลงทะเบียนจากระยะไกล ไม่เรียกใช้ API ของผู้ลงทะเบียน และไม่ทำการทดสอบพิสูจน์การควบคุมใด ๆ
แทนที่จะเป็นเช่นนั้น Webship จะเก็บเส้นทางการออกเอกสารส่วนตัวทั้งหมดไว้ในกระบวนการเดียว:
- ไซต์เลือก certificate_mode = "embedded"
- Webship โหลดหรือสร้างตัวตนรากส่วนตัวในไดเรกทอรีสถานะที่กำหนดค่าไว้
- Webship สร้างกุญแจส่วนตัวใหม่สำหรับเว็บไซต์
- รากฝังลงลายเซ็นใบรับรองของใบสำหรับชื่อนั้นโดยตรง
- Webship ตรวจสอบตัวตนที่สมบูรณ์ก่อนติดตั้งในตัวแก้ไข TLS ที่ใช้งานจริง
- จากนั้นใบรับรองจะสามารถใช้ได้กับทุกโปรโตคอลที่เปิดใช้งานสำหรับไซต์นั้น
ความท้าทายเครือข่ายสไตล์ ACME จะพิสูจน์ Webship เพียงต่อตัวมันเอง ดังนั้นเส้นทางที่ฝังอยู่จึงไม่มีโปรโตคอลเครือข่ายตั้งใจไว้ ส่วน [acme_ca] เป็นสถานะ PKI ส่วนตัว: มันกำหนดว่ารากอยู่ที่ไหนและใบรับรองใบเล็กที่ออกมีอายุการใช้งานนานเท่าใด
กำหนดค่าการรับรองความถูกต้องแบบฝังสำหรับเว็บไซต์หนึ่ง
นี่คือรูปทรงขั้นต่ำสำหรับไซต์ส่วนตัว:
~~~ทอมแอล ฟัง = "0.0.0.0:443"
[tls] unknown_sni = "ปฏิเสธ"
[อัตโนมัติ_tls] เปิดใช้งาน = จริง cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[ไซต์]] โดเมน = "service.internal.example" root = "/srv/service" certificate_mode = "ฝังตัว"
[ไซต์.โปรโตคอล] h1 = จริง h2 = จริง h3 = จริง ~~~
รากของเอกลักษณ์จะถูกสร้างแบบขี้เกียจเมื่อเว็บไซต์ที่ฝังอยู่ต้องการมันเป็นครั้งแรก Webship เก็บคีย์รากด้วยสิทธิ์จำกัดใน state_dir ใบรับรองรากมีอายุการใช้งานสิบปี; อายุการใช้งานของใบรับรองใบไม้ถูกควบคุมโดย leaf_validity_days
ปฏิบัติต่อทั้งสองสถานที่เก็บข้อมูลเสมือนอยู่ในสถานะการผลิต:
- แคช ACME เก็บตัวตนของเว็บไซต์ที่ถูกจัดการโดยอัตโนมัติ
- ไดเร็กทอรีสถานะ embedded-CA เก็บตัวตนรากส่วนตัว
- บัญชีบริการต้องการสิทธิ์เข้าถึง แต่ผู้ใช้แอปพลิเคชันไม่ต้องการ
- การสำรองข้อมูลต้องรักษาความลับและสิทธิ์การเข้าถึงไฟล์
- การผลิต การพัฒนา และการทดสอบควรใช้รากและไดเรกทอรีแยกกัน
การลบไดเรกทอรีรากไม่ได้เป็นการ “รีเซ็ต TLS” มันสร้างจุดเชื่อถือใหม่ ลูกค้าที่เชื่อถือรากเดิมจะปฏิเสธใบรับรองที่ออกโดยตัวแทนใหม่จนกว่าร้านค้าความเชื่อถือของพวกเขาจะได้รับการอัปเดต
ความไว้วางใจส่วนตัวเกิดจากความตั้งใจ
ใบรับรองจาก CA ที่ฝังอยู่จะไม่ถูกเชื่อถือโดยอัตโนมัติโดยเบราว์เซอร์สาธารณะหรือระบบปฏิบัติการ พวกมันจะได้รับการเชื่อถือก็ต่อเมื่อผู้ดำเนินการติดตั้งใบรับรองราก Webship ที่ส่งออกไว้ในที่เก็บความเชื่อถือของไคลเอนต์
นั่นทำให้โหมดฝังตัวเหมาะสมสำหรับ:
- แล็ปท็อปและโทรศัพท์ที่บริษัทจัดการซึ่งลงทะเบียนผ่านการจัดการอุปกรณ์;
- การรับส่งข้อมูลภายในระหว่างบริการกับบริการโดยใช้ชุด CA ที่ชัดเจน
- อุปกรณ์ใช้ในบ้านส่วนตัวและกองยานพาหนะที่ควบคุมขอบเขต;
- สภาพแวดล้อมการพัฒนาและทดสอบที่ต้องใช้พฤติกรรม TLS จริง;
- เครือข่ายที่แยกตัวซึ่งไม่สามารถพึ่งพา CA สาธารณะได้
นี่ไม่ใช่โหมดที่เหมาะสมสำหรับเว็บไซต์สาธารณะทั่วไปที่ผู้เข้าชมใช้เบราว์เซอร์ที่ไม่ได้จัดการ ใช้การออกใบรับรองต่อไซต์สาธารณะสำหรับชื่อสาธารณะที่แน่นอน การออกใบรับรองแบบ fleet สำหรับชุดซับโดเมนสาธารณะขนาดใหญ่ ใช้แบบแชร์เฉพาะสำหรับการติดตั้งหลาย SAN แบบเก่าที่จงใจ หรือใช้ไฟล์ด้วยตนเองจาก PKI ที่เชื่อถือแล้ว
แจกจ่ายเฉพาะใบรับรองรากแก่ลูกค้า ห้ามแจกจ่ายกุญแจส่วนตัวรากเด็ดขาด การครอบครองกุญแจนั้นจะมอบอำนาจแก่ผู้ถือในการออกตัวตนที่ลูกค้าที่สมัครทุกคนเชื่อถือได้
ใบรับรองสาธารณะและเอกชนสามารถอยู่ร่วมกันได้
Webship 1.4.0 สามารถผสมผสานกลยุทธ์ใบรับรองบนตัวฟังเดียวกันได้:
~~~ทอมแอล ฟัง = "0.0.0.0:443"
[tls] unknown_sni = "ปฏิเสธ"
[อัตโนมัติ_tls] เปิดใช้งาน = จริง directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] ยอมรับ_ข้อกำหนดการให้บริการ = จริง
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[ไซต์]] โดเมน = "www.example.com" root = "/srv/public" certificate_mode = "ต่อ_ไซต์"
[[ไซต์]] โดเมน = "control.internal.example" root = "/srv/control" certificate_mode = "ฝังตัว"
[[ไซต์]] โดเมน = "payments.example.com" root = "/srv/payments"
[ไซต์.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~
ที่นี่ www.example.com ได้รับใบรับรอง ACME สาธารณะของตัวเอง ส่วน control.internal.example ได้รับใบรับรองส่วนตัวจาก CA ที่ฝังอยู่ payments.example.com ยังคงอยู่ภายใต้ PKI ภายนอกของผู้ดำเนินการเพราะไฟล์ที่ชัดเจนของมันมีลำดับความสำคัญเหนือกว่า
ไดเรกทอรี ACME สาธารณะจะถูกละเว้นโดยไซต์ที่ฝังอยู่ รากฝังตัวไม่เคยเซ็นไซต์สาธารณะ ไซต์คู่มือจะไม่ถูกลงทะเบียนโดยเงียบในทั้งสองเวิร์กโฟลว์อัตโนมัติ
ตัวแก้ไขใบรับรองหนึ่งชุดสำหรับ H1, H2, H3 และ WebTransport
การเลือกใบรับรองเกิดขึ้นระหว่างการจับมือ TLS ก่อนที่คำขอ HTTP จะปรากฏ Webship ใช้ชื่อเซิร์ฟเวอร์ ClientHello เพื่อเลือกตัวตนของไซต์แล้วจึงเจรจาต่อรองโปรโตคอลแอปพลิเคชัน
- HTTP/1.1 และ HTTP/2 ใช้ TLS ผ่าน TCP
- HTTP/3 และ WebTransport ใช้ TLS ภายใน QUIC บน UDP
- หนึ่งตัวตนของไซต์ที่ถูกต้องสามารถใช้กับทุกโปรโตคอลที่เปิดใช้งานได้
- HTTP/3 ยังต้องการความสามารถในการเข้าถึง UDP; H1 และ H2 ใช้เส้นทาง TCP
- Alt-Svc สามารถโปรโมท H3 ในขณะที่ยังคงรักษาการสำรอง TCP ได้
TCP TLS และ QUIC ใช้โมเดลตัวตนแบบตระหนักรู้ไซต์เดียวกัน ชื่อที่ตรงกันจะมีความสำคัญก่อน ชื่อไวด์การ์ดที่ถูกต้องยาวที่สุดจะชนะเมื่อมีการกำหนดค่าใบรับรองไวด์การ์ด และ SNI ที่ไม่ทราบชื่อสามารถถูกปฏิเสธแทนการรับใบรับรองเริ่มต้นที่ไม่เกี่ยวข้อง
ใช้ unknown_sni = "reject" บนตัวฟังหลายไซต์เมื่อชื่อโฮสต์ที่ไม่รู้จักต้องล้มเหลวแบบปิด ทดสอบชื่อที่รู้จัก ชื่อที่ไม่รู้จัก และพฤติกรรม no-SNI ที่คุณคาดหวังก่อนการใช้งานจริง
หมุนเอกลักษณ์ที่ฝังไว้โดยไม่เว้นว่างด้านการให้บริการ
Webship เปิดเผยสถานะของใบรับรองและการเปลี่ยนแปลงที่ควบคุมผ่านเซิร์ฟเวอร์ MCP ที่ตรวจสอบสิทธิ์และผูกกับ loopback ของมัน:
- webship.tls.get_status รายงานตัวแก้ปัญหาใบรับรองที่ใช้งานอยู่และสถานะการต่ออายุ
- webship.tls.reissue_certificate จะออกใบรับรองใหม่โดยอัตโนมัติให้กับไซต์ที่จัดการโดยอัตโนมัติเพียงเมื่อไซต์นั้นใช้โหมดฝังตัวเท่านั้น
- webship.tls.reload รีโหลดสถานะใบรับรองผ่านเส้นทาง TLS ที่ป้องกันตามปกติ
- webship.acme_ca.status รายงานว่ามีการเลือก CA ส่วนตัวหรือไม่ ไดเรกทอรีสถานะ ช่วงเวลาการใช้งานของใบรับรองปลายทาง จำนวนการออกใบรับรอง จำนวนการเพิกถอน และตัวอย่างโดเมนล่าสุด
- webship.sites.apply เพิ่มหรือเอาไซต์ออกจากเวอร์ชันการกำหนดค่าที่ปักหมุดอยู่
สำหรับการออกใหม่แบบฝังตัว Webship จะสร้างและตรวจสอบตัวทดแทนก่อนสลับเข้าใช้งาน ตัวตนที่ถูกต้องปัจจุบันยังคงให้บริการจนกว่าตัวตนใหม่จะพร้อม ตัวตนที่ถูกยกเลิกจะถูกบันทึกก็ต่อเมื่อการติดตั้งตัวทดแทนเสร็จสมบูรณ์
การดำเนินการออกใหม่ทันทีจะปฏิเสธใบรับรอง per_site สาธารณะโดยเจตนา การต่ออายุสาธารณะต้องอยู่ภายในวงจรชีวิต ACME สาธารณะต่อไป ไม่ใช่สับสนกับการลงนามในกระบวนการส่วนตัว สมาชิกแบบโหมดแบ่งปันก็ถูกหยุดชั่วคราวเช่นกัน เนื่องจากการเปลี่ยนกลุ่ม multi-SAN จะสร้างขอบเขตตัวตนขึ้นใหม่
MCP เป็นพื้นผิวการควบคุมที่มีสิทธิพิเศษ เก็บไว้ในโหมด loopback ต้องใช้ TLS และโทเค็นผู้ถือที่แข็งแกร่ง ใช้ช่องทางที่มีการยืนยันตัวตนสำหรับการบริหารระยะไกล และตรวจสอบการเปลี่ยนแปลงทุกครั้ง
ขอบเขตความล้มเหลวที่สำคัญ
ระบบใบรับรองที่ปลอดภัยต้องล้มเหลวในทิศทางที่ถูกต้อง
- ไซต์ฝังตัวที่กำหนดค่าใหม่จะไม่ได้รับตัวตนของไซต์อื่นในขณะที่การออกกำลังอยู่ระหว่างรอดำเนินการ
- การเปลี่ยนทดแทนที่ไม่ถูกต้องไม่ได้ถูกติดตั้งเหนือใบรับรองที่ใช้งานอยู่
- ไฟล์คู่มือที่ชัดเจนจะป้องกันไม่ให้เกิดความเป็นเจ้าของเว็บไซต์โดยอัตโนมัติ
- ชื่อ SNI ที่ไม่รู้จักสามารถถูกปฏิเสธก่อนการกำหนดเส้นทาง HTTP
- CA ที่ฝังอยู่ยังคงเป็นส่วนตัวและไม่มีจุดสิ้นสุดการลงทะเบียนจากระยะไกล
- เอกลักษณ์สาธารณะและฝังตัวใช้เส้นทางแคชแยกกันภายในสถานะ automatic-TLS
คำเตือนว่าการฝัง CA ยังไม่ได้รับการเริ่มต้นหมายความว่า Webship ไม่สามารถตั้งค่าดัชนีสถานะที่กำหนดได้ แก้ไขเจ้าของไฟล์ สิทธิ์ ความคงทน หรือความพร้อมใช้งานของพื้นที่เก็บข้อมูลก่อนส่งทราฟฟิกไปยังไซต์ที่ได้รับผลกระทบ อย่าวิธีแก้ไขข้อผิดพลาดโดยการคัดลอกคีย์รากจากสภาพแวดล้อมอื่น
รายการตรวจสอบการผลิต
ก่อนเปิดใช้งานโหมดฝังตัว:
- ระบุประชากรลูกค้าทุกกลุ่มที่ต้องไว้วางใจเว็บไซต์
- สร้างกระบวนการที่ควบคุมได้สำหรับการส่งออกและติดตั้งใบรับรองราก
- ใช้สถานะรากแยกสำหรับการผลิต การพัฒนา และการทดสอบ
- ดำรงไว้และปกป้องไดเรกทอรีสถานะ CA ที่ฝังอยู่และแคช TLS อัตโนมัติ
- เรียกใช้ Webship ภายใต้บัญชีบริการเฉพาะที่มีสิทธิ์เข้าถึงเฉพาะวัสดุกุญแจที่จำเป็นเท่านั้น
- เลือก certificate_mode ในทุกไซต์ที่ขอบเขตความน่าเชื่อถือของต้องชัดเจน
- ตั้งค่าและทดสอบนโยบาย SNI ที่ไม่ทราบ
- เปิดใช้งาน H1, H2 และ H3 โดยตั้งใจและตรวจสอบทั้งเส้นทาง TCP และ UDP
- ฝึกซ้อมการออกใหม่ การเริ่มต้นใหม่ การสำรองข้อมูล การกู้คืน และการตรวจสอบความน่าเชื่อถือของลูกค้านอกการผลิต
- รัน webship --check-config ก่อนการเปิดตัว จากนั้นตรวจสอบผู้ให้บริการ ชื่อ ความถูกต้อง โซ่ และโปรโตคอลที่เจรจากับลูกค้าจริง
เลือกความไว้วางใจเป็นอันดับแรก อัตโนมัติเป็นอันดับสอง
CA ที่ฝังอยู่ช่วยลดความขึ้นต่อบริการใบรับรองภายนอกสำหรับโครงสร้างพื้นฐานส่วนตัว แต่ไม่ได้ทำให้รากส่วนตัวได้รับความเชื่อถือทั่วโลก และไม่ได้ลดความรับผิดชอบของผู้ดำเนินงานในด้าน PKI
Webship ทำงานอัตโนมัติในการสร้างกุญแจ การลงนาม การตรวจสอบ การติดตั้ง การหมุนเวียน และการเลือกใบรับรองในทุกโปรโตคอล ผู้ปฏิบัติงานยังคงเป็นเจ้าของการดูแลราก การลงทะเบียนผู้ใช้ การแยกสภาพแวดล้อม การสำรองข้อมูล การกู้คืน และการตัดสินใจใช้เส้นทางความเชื่อถือสาธารณะหรือส่วนตัว
การแยกนั้นคือคุณสมบัติ เซิร์ฟเวอร์ที่แยกตัวเองออกมาได้สามารถทำให้ TLS ส่วนตัวทำงานอัตโนมัติโดยไม่ต้องแกล้งทำเป็น CA สาธารณะ — และเว็บไซต์สาธารณะยังคงสามารถใช้การออกใบรับรองต่อไซต์หรือแบบกลุ่มที่เบราว์เซอร์เชื่อถือได้ในกระบวนการเดียวกัน
อ่านเอกสาร Webship 1.4.0 ที่มีเวอร์ชัน ก่อนการเปิดตัว RFC 5280 กำหนดโปรไฟล์และการตรวจสอบใบรับรอง, RFC 6066 กำหนดการส่งสัญญาณชื่อเซิร์ฟเวอร์ TLS, RFC 8446 กำหนด TLS 1.3, RFC 8555 กำหนด ACME สาธารณะ, และ RFC 9525 กำหนดการตรวจสอบตัวตนบริการ