Let's Encrypt กำลังเตรียมออกใบรับรองสำหรับที่อยู่ IP

 (community.letsencrypt.org)
7 คะแนน โดย GN⁺ 2025-06-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Let's Encrypt จะรองรับการออกใบรับรองที่มี IP address SAN ในเร็ว ๆ นี้ โดยในช่วงแรกจะให้ใช้งานเฉพาะ โปรไฟล์ shortlived ที่หมดอายุภายใน 6 วัน และจะเปิดใช้งานแบบจำกัดด้วย ระบบ allowlist อยู่ระยะหนึ่ง
  • ก่อนเปิดใช้งานอย่างเป็นทางการ ยังไม่มีการประกาศกำหนดการหรือวิธีสมัครอย่างละเอียด โดยขณะนี้กำลังทดสอบภายในและเตรียมความพร้อมอยู่
  • ในสภาพแวดล้อม staging ได้มีการเผยแพร่ ใบรับรองตัวอย่างที่มี IPv6 address รวมอยู่ด้วย และเว็บไซต์ที่นำไปใช้งานจริง พร้อมขอให้ชุมชนช่วยแชร์ความผิดปกติหรือข้อเสนอแนะ
  • พบบั๊กใน Firefox ที่เกี่ยวข้องกับการแสดงผล IP SAN (BZ #1973855) และยังคงมีการทดสอบต่อเนื่อง
  • มีการยืนยันจากตัวอย่างทดสอบจริงว่ากรณีที่ผสม DNS SAN กับ IP SAN อาจทำให้เกิดความสับสนได้ โดยสาธิตให้เห็นว่าการแสดงผลของ TLD กับ IPv6 address อาจดูคล้ายกัน

Let's Encrypt, กำลังเตรียมออกใบรับรองสำหรับที่อยู่ IP

สถานะการเตรียมรองรับ IP address SAN

  • Let's Encrypt มีแผนจะ รองรับการออกใบรับรองที่มี IP address SAN ใน production environment เร็ว ๆ นี้
  • ใบรับรองดังกล่าวจะออกได้เฉพาะใน โปรไฟล์ shortlived ที่มีอายุใช้งาน 6 วัน เท่านั้น และในช่วงหนึ่งจะเปิดใช้งานแบบจำกัดด้วย allowlist
  • ขณะนี้ ยังไม่มีกำหนดเปิดตัวอย่างเป็นทางการหรือวิธีสมัคร allowlist ที่แน่ชัด และยังต้องมีการเตรียมการภายในเพิ่มเติม

การทดสอบและใบรับรองตัวอย่าง

  • มีการเผยแพร่ตัวอย่าง ใบรับรองที่มี IP SAN และเว็บไซต์ที่นำไปใช้งานจริง (ที่อยู่ IPv6) ใน staging environment
  • ทีมงานขอให้ผู้ใช้ในชุมชนช่วย แชร์ความผิดปกติ จุดที่น่าสนใจ หรือปัญหาที่พบ

กรณีผสม IP SAN และ DNS SAN

  • มีการสาธิตความเป็นไปได้ในการออกใบรับรองที่มี DNS SAN และ IP SAN พร้อมกัน รวมถึงกรณีความสับสนจากการแสดงผล
  • การแสดงผลของ TLD บางประเภท เช่น .cafe อาจดูคล้ายกับที่อยู่ IPv6 จึงมีโอกาสทำให้สับสนได้
  • ยังพบ บั๊กใน Firefox ที่เกี่ยวข้องกับการแสดงผล IP address SAN (BZ #1973855) ด้วย

สรุป

  • การรองรับ ใบรับรองสำหรับที่อยู่ IP ของ Let's Encrypt จะเริ่มแบบจำกัดก่อนด้วย allowlist และใบรับรองระยะสั้น
  • ก่อนนำไปใช้กับบริการจริง จะมีการทดสอบหลายกรณีและรับฟัง feedback จากชุมชน เพื่อตรวจสอบเสถียรภาพและความเข้ากันได้
  • ประเด็นเรื่อง การแสดงผลในเบราว์เซอร์เมื่อมีการใช้ SAN แบบผสมระหว่างชื่อ DNS กับที่อยู่ IP ก็ถูกหยิบยกมาพูดถึงเช่นกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-27
ความคิดเห็นบน Hacker News

  • คิดว่าใบรับรองสำหรับที่อยู่ IP ก็มีประโยชน์เหมือนกัน
    แต่คิดว่าถ้า Let’s Encrypt รองรับใบรับรอง S/MIME ได้ จะส่งผลกระทบได้มากกว่านี้มาก
    หลายปีมานี้มีสถานการณ์ชวนขำเกี่ยวกับการเข้ารหัสอีเมลเกิดขึ้นอยู่
    ตอนนี้ไคลเอนต์อีเมลหลักส่วนใหญ่รองรับการเข้ารหัส S/MIME ได้ทันทีแล้ว แต่เช่นเดียวกับเว็บ หากต้องการประสบการณ์ใช้งานที่ลื่นไหลก็ยังต้องขอใบรับรองจาก CA
    ตอนนี้ CA ที่น่าเชื่อถือ ฟรี และออกใบรับรอง S/MIME ที่มีอายุมากกว่า 1 ปีได้ ล้วนหายไปหมดแล้ว
    ผลก็คือผู้ใช้ทั่วไปแทบไม่ใช้การเข้ารหัสอีเมลกันเลย
    PGP ใช้งานยากเกินไปจนแทบไม่มีใครใช้นอกจากพวกสายเทคนิค
    คิดว่าตอนนี้เราควรเข้ารหัสอีเมลกันได้แล้ว
    ขอเสริมว่า ถ้า CA เป็นคนสร้าง private key ให้แทน ก็ถือว่าใบรับรองนั้นไม่น่าเชื่อถือ
    อีกอย่าง S/MIME ต้องเก็บใบรับรองเก่าไว้ต่อเพื่อถอดรหัสอีเมลเก่า ดังนั้นใบรับรองที่เปลี่ยนบ่อยจึงไม่ค่อยใช้งานได้จริง

    • เรื่องที่บอกว่าต้องใช้ใบรับรองเก่าเพื่อถอดรหัสอีเมลเก่าใน S/MIME นั้น มองว่าไม่จำเป็นต้องเปลี่ยนบ่อยเสมอไป เพราะตัวกุญแจถอดรหัสเองสามารถสร้างใบรับรองใหม่โดยใช้กุญแจเดิมได้อยู่แล้ว (เช่น ตัวเลือก --reuse-key ของ certbot)
      แต่จะเป็นวิธีที่ดีหรือไม่ก็เป็นอีกเรื่องหนึ่ง
      สิ่งที่ต้องการจริง ๆ คือระบบอัตโนมัติสำหรับออกใบรับรองแบบ ACME
      ตอนนี้กระบวนการต่ออายุใบรับรองยุ่งยากเกินไปจนแทบไม่มีใครใช้

    • ตอนนี้ PGP มีวิธีชื่อ WKD(Web Key Directory)ลิงก์ ซึ่งทำให้สามารถใช้เครือข่ายความเชื่อถือของ TLS กับอีเมลได้
      ตอนนี้ใบรับรอง TLS ขอได้ง่ายกว่าใบรับรอง S/MIME มาก
      การให้บุคคลที่สามจัดการตัวตนอาจช่วยได้ แต่คนส่วนใหญ่มักทำงานในบริษัทที่รูปแบบการจัดการตัวตนแบบนั้นไม่ค่อยเหมาะ
      ถ้าเป็นบริษัท ก็มองว่าการจัดการตัวตนภายในองค์กรเองน่าจะเหมาะกว่า
      เหตุการณ์วุ่นวาย Signalgate 1.0 ที่เพิ่งเกิดขึ้นลิงก์ ถือว่าน่าเรียนรู้มากในแง่ที่มันเป็นความล้มเหลวของการจัดการตัวตนในระบบเข้ารหัสแบบ end-to-end
      ทำให้คิดว่าถ้ามีการนำใบรับรอง S/MIME หรือ WKD ไปใช้เป็นระบบที่ใช้งานได้จริง รัฐบาลก็น่าจะได้ประโยชน์ด้วย

    • โดยส่วนตัวมองแนวโน้มของการเข้ารหัสอีเมลแบบ S/MIME ในแง่บวก แต่รู้สึกว่าความเป็นไปได้ในการเกิดขึ้นจริงค่อนข้างต่ำ
      ผู้ใช้ทั่วไปจำนวนมากยังจัดการ private key ไม่ไหว และในความเป็นจริงแม้แต่รหัสผ่านอีเมลก็ยังดูแลกันได้ไม่ดีนัก
      สุดท้ายก็จะกลายเป็นว่าต้องมีการออกใบรับรองแบบรวมศูนย์ในแต่ละโดเมน หรือไม่เช่นนั้นผู้ใช้ก็จะไม่ได้รับใบรับรอง ขณะเดียวกันอาชญากรไซเบอร์ก็จะส่งอีเมลที่เซ็นด้วย S/MIME กันได้
      คิดว่าเมื่อการใช้ passkey กลายเป็นเรื่องปกติและมีการเปลี่ยนผ่านทางรุ่นแล้ว ตอนนั้นค่อยให้ผู้ใช้จัดการคู่กุญแจด้วยตัวเองน่าจะเหมาะกว่า

    • มีความเห็นว่าการเข้ารหัสอีเมลควรหายไปเสียที
      อ้างอิง: Stop using encrypted email

    • ไม่ค่อยรู้เรื่องการเข้ารหัส S/MIME เลยมีข้อสงสัย
      สงสัยว่าทำไมต้องใช้โปรโตคอลเดียวกันมาถอดรหัสอีเมลเก่าด้วย
      ส่วนตัวคิดว่าใบรับรองมีไว้สำหรับช่วงขนส่งข้อมูล (transport) และตอนจัดเก็บจริงก็น่าจะมีการเข้ารหัสสำหรับการเก็บรักษาบนเซิร์ฟเวอร์หรือโฮสต์แยกอยู่แล้ว ดังนั้นการใช้ใบรับรองระยะสั้นสำหรับการส่ง และใช้การเข้ารหัสแบบอื่นตามต้องการสำหรับการจัดเก็บก็ดูสมเหตุสมผล เลยสงสัยว่าตัวเองพลาดอะไรไปหรือเปล่า

  • สงสัยว่าหน่วยงานที่ดูแลที่อยู่ทั้งหมด (เช่น ISP, ผู้ให้บริการคลาวด์) จะเข้าร่วมกระแสนี้กันหมดหรือไม่
    บางแห่งหมุนเวียน IP เร็วมาก บางครั้งเร็วกว่าทุก 6 วันด้วยซ้ำ
    ถ้าผู้ให้บริการคลาวด์มีช่วง cooldown สำหรับการวิเคราะห์ IP หรือมีการค้นหาและเพิกถอนใบรับรองที่เกี่ยวข้องกับ IP นั้นก็คงพอเข้าใจได้ แต่ถ้าไม่ทำ ก็จะเกิดความซับซ้อนที่ผู้ใช้ต้องรับผิดชอบในการตรวจสอบ host header เอง ปฏิเสธการเชื่อมต่อแบบอิง IP ที่ไม่ต้องการ หรือรอจนกว่าใบรับรองแบบเก่าจะหมดไปทั้งหมด
    และก็สงสัยด้วยว่าในผู้ให้บริการคลาวด์แต่ละราย จะขอใบรับรอง IP ได้มากแค่ไหน และมีค่าใช้จ่ายเท่าไร

    • จริง ๆ แล้วคิดว่าปัญหานี้แทบไม่ต่างจากการที่ผู้ให้บริการคลาวด์ให้โดเมนแบบ custom/vanity
      เช่นใน Azure สามารถผูก DNS อย่าง myapp.westus.cloudapp.azure.com เข้ากับ VM ได้ และใคร ๆ ก็สามารถขอใบรับรองสำหรับโดเมนนั้นจาก CA ได้ อ้างอิง
      ในกรณีแบบนี้ ถ้า VM ถูกลบ คนอื่นก็สามารถเอาโดเมนนั้นไปใช้ต่อได้ทันทีโดยไม่มี cooldown แยกต่างหากเช่นกัน

    • ใบรับรอง HTTPS สามารถต่ออายุแบบมีอายุ 90 วันได้ตั้งแต่หนึ่งวันก่อนโดเมนหมดอายุ และ CA ก็ไม่อาจรู้วงเงินบัตรชำระเงินได้
      คนที่ใช้ใบรับรอง IP ส่วนใหญ่คงไม่ใช่กลุ่มเดียวกับผู้ใช้ที่ปล่อย IP ทิ้งอย่างรวดเร็วแล้วจากไป
      กรณีที่มีประโยชน์ที่สุดน่าจะเป็นซอฟต์แวร์ legacy ที่เฉพาะทางมาก ๆ หรือกรณีที่ต้องการรองรับ ECH(Encrypted Client Hello) หรือ ESNI(Encrypted SNI) โดยไม่ใช้ shared IP แบบ Cloudflare
      กรณีแรก (legacy) ก็คงไม่ยอมปล่อย IP ง่าย ๆ ส่วนกรณีที่สอง (ECH/ESNI) ก็มองว่าโดยทั่วไปเข้าถึงโดเมนจริงให้สำเร็จได้ยาก

    • สำหรับคำถามว่า ISP ต้องเข้าร่วมหรือไม่ ผมกลับมองว่ามันควรเป็นอีกทาง
      หน้าที่ของ ISP ไม่ใช่การจัดสรร IP ให้สอดคล้องกับมาตรฐาน TLS แต่ผู้ให้บริการออกใบรับรอง TLS ต่างหากที่ควรทำหน้าที่ "ยืนยันตัวตน" ให้สอดคล้องกับวิธีที่ระบบนิเวศผูกตัวตนเข้ากับสิ่งต่าง ๆ (โดเมน, IP ฯลฯ)
      รอบนี้ยังไม่มีรายละเอียดว่าจะเข้าหาเรื่องนี้อย่างไร แต่สัญชาตญาณผมบอกว่า LetsEncrypt น่าจะทำรายชื่อ IP ที่มีการโอนย้ายระยะยาวตาม ASNs(Autonomous System Numbers) ขึ้นมา (ร่วมดูแลเหมือนฐานข้อมูลสาธารณะอย่าง Mozilla Public Suffix List) แล้วออกใบรับรองให้เฉพาะ IP ที่อยู่ในรายชื่อนั้นเท่านั้น และหากย้ายไป ASN อื่นก็น่าจะมีการจัดการเพิกถอนใบรับรอง
      หวังว่าจะใช้วิธีที่แชร์ร่วมกับผู้ออกใบรับรอง ACME รายอื่นด้วย

    • ถ้าอยากรู้ว่าในคลาวด์ต่าง ๆ จะขอใบรับรอง IP ได้กี่ใบและราคาเท่าไร ก็เลยสงสัยต่อด้วยว่าในอนาคตจะมีการรองรับใบรับรอง wildcard หรือไม่

    • ในกรณีของผม แค่มีใบรับรอง IP เพียงวันเดียวก็พอสำหรับการทดสอบ URL แบบ https แล้ว เลยมองว่าเป็นการเปลี่ยนแปลงที่น่ายินดีมาก

  • ในทางเทคนิคเข้าใจว่ามันทำงานอย่างไร แต่สงสัยว่ากรณีใช้งานที่ตั้งใจไว้จริง ๆ คืออะไร

    • แค่รองรับ ECH(Encrypted Client Hello) หรือ ESNI(Encrypted SNI) ก็มีความหมายมากแล้ว
      ช่วงแรกของ ESNI มีแค่ HTTPS proxy รายใหญ่อย่าง Cloudflare เท่านั้นที่ใช้งานได้ ทำให้การมีใบรับรอง IP ดูเหมือนเป็นไอเดียในฝัน แต่ตอนนี้ทุกเซิร์ฟเวอร์สามารถเข้าร่วมกับ ESNI/ECH ได้แล้ว
      ถ้าฝั่งไคลเอนต์เริ่มสมมติว่าทุกเซิร์ฟเวอร์มีใบรับรอง IP และลองใช้ ESNI กัน ก็หวังว่าจะช่วยยกระดับความเป็นส่วนตัวของอินเทอร์เน็ตโดยรวมได้มาก

    • ในหลายคำตอบมีตัวอย่างการใช้งานดี ๆ ออกมาแล้ว แต่ NTS(Network Time Security) ก็น่าพูดถึงเหมือนกัน
      ถ้าขอใบรับรอง IP ไม่ได้ NTS ก็ต้องพึ่ง DNS ด้วย ซึ่งหมายความว่าถ้า DNS ล่ม การซิงก์เวลาด้วยการยืนยันตัวตนก็จะทำไม่ได้เลย
      DNSSEC เองก็จะตรวจสอบไม่ผ่านหากเวลาไม่ถูกต้อง และถ้ายังพึ่ง DNS+NTS อยู่ก็จะกู้ระบบกลับมาไม่ได้
      ถ้ามีใบรับรองที่ใส่ IP ไว้ได้ ก็จะกระจายเวลาที่ตรวจสอบตัวตนแล้วได้โดยไม่ต้องใช้ DNS และช่วยแก้ปัญหานี้ได้

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

    • น่าจะเป็นแนวทางที่น่าสนใจเวลาใช้ DoTLS(DNS over TLS แบบคาดหวังตามโอกาส) กับ authdns(เซิร์ฟเวอร์ DNS แบบ authoritative)
      เซิร์ฟเวอร์ DNS แบบ authoritative สามารถให้บริการบนพอร์ต DoTLS โดยใช้ใบรับรองที่มี public IP อยู่ใน SAN(Subject Alternative Name) ได้
      ตอนนี้ก็ทำด้วย hostname ได้อยู่แล้ว แต่เพราะ public IP เดียวอาจมีหลายชื่อที่ต่างกันอยู่ได้ การมี SAN แบบอิง IP จะผูกความสัมพันธ์ได้ชัดเจนกว่า

    • คิดว่าเหมาะกับคนที่อยากเชื่อมต่อโปรเจ็กต์เข้ากับ IP โดยตรงแทน hostname หรืออยากใช้งานแบบไม่มีโดเมนเพื่อจุดประสงค์งานอดิเรกหรือใช้ครั้งเดียว

  • สงสัยว่าทำไมองค์กรทะเบียนอินเทอร์เน็ตระดับภูมิภาค(RIR) หรือผู้รับจดทะเบียนท้องถิ่น(LIR) ถึงไม่เป็นผู้ออกใบรับรองเอง
    ทำไมบุคคลที่สามต้องมาเป็นผู้ยืนยันผู้ลงทะเบียนกับ RIR, LIR ด้วย เป็นเพราะผู้ลงทะเบียนโดเมนมีงานมากเกินไปหรือ
    ไม่แน่ใจว่าเหตุผลจะเหมือนกันหรือไม่

  • รู้สึกเหมือนมีช่องทางใหม่ให้เอา TLS ไปใช้ในทางที่ผิดเพิ่มขึ้น
    ก่อนหน้านี้ปัญหาคือการออกใบรับรองให้โดเมนที่ไม่ได้เป็นเจ้าของ แต่ตอนนี้อาจเกิดการออกใบรับรองให้ IP ที่ไม่ได้เป็นเจ้าของได้ด้วย
    พวก black hat คงคุยกันอย่างออกรสใน Telegram

    • ที่จริงใบรับรอง IP มีมานานแล้ว สิ่งที่เปลี่ยนคือแค่ตอนนี้ Let's Encrypt จะให้บริการมันด้วยเท่านั้น

  • สงสัยว่าอย่างนี้จะทำให้เข้า https ไปยังหน้าจัดการเราเตอร์ภายในเครื่อง (เช่น 192.168.0.1) ได้โดยไม่เจอข้อผิดพลาด self-signed หรือไม่

    • ทำไม่ได้ แต่ก็อาจเป็นไปได้ในอนาคต
      ที่อยู่ภายในไม่ได้ถูกจัดสรรแบบสากลและไม่ได้มีการเราต์ทั่วโลก จึงไม่มีวิธียืนยันโดยเนื้อแท้
      แต่ถ้าผู้ผลิตเราเตอร์ตั้งใจทำ และอุปกรณ์นั้นไม่ได้อยู่หลัง CG-NAT พร้อมทั้งได้รับ public IPv4 จริง ก็อาจขอใบรับรองด้วยที่อยู่สาธารณะนั้นได้
      ส่วน IPv6 ส่วนใหญ่เราต์ได้ทั่วโลกอยู่แล้ว เลยมองว่ายิ่งง่ายกว่า

    • ทำไม่ได้ และก็ไม่ควรทำได้ด้วย
      ในทางปฏิบัติ แค่ใช้ proxy ร่วมกับโดเมนจริงและใบรับรองจริง แล้วผสมกับฟังก์ชัน DNS rewrite ก็พอแล้ว
      ตัวอย่างเช่น ใช้ nginx manager UI และใช้ adguard เป็น DNS
      จำกัด DNS ของเราเตอร์ให้ใช้ adguard แล้ว rewrite โดเมนของตัวเองไปที่ proxy
      พอจดโดเมนและขอใบรับรองจริงก็จบ
      ผมเองก็ใช้ https กับทุกบริการภายในเครื่องเหมือนกัน

    • จะไม่มีการออกใบรับรองให้ private IP
      เพราะ private IP เดียวกันอาจชี้ไปยังอุปกรณ์ที่ต่างกันโดยสิ้นเชิงในเครือข่ายอื่นได้ตลอด และไม่มีการรับประกันความเป็นเจ้าของแบบผูกขาด

    • ตรงกันข้ามเลย
      ถ้าไม่ใช่ public IP ก็ออกใบรับรองที่ใช้งานได้ไม่ได้
      ตอนนี้มีวิธีขอใบรับรองโดเมนอยู่แล้ว แล้วค่อย forward โดเมนนั้นไปที่ 192.168.0.1

    • ถ้าจะขอใบรับรอง ก็ต้องเป็นเจ้าของ IP นั้นจริง ๆ (public IP)

  • อยากรู้ว่าจะทำใบรับรองสำหรับ IPv4 ภายใน (192.168.x.x, 172.16.x.x, 10.x.x.x) ได้หรือไม่ หรือจริง ๆ แล้วเบราว์เซอร์ควรเมินที่อยู่แบบนี้ไปเลย และถ้าไม่ใช่ อย่างน้อยจะมีทางออกใบรับรอง wildcard สำหรับเครือข่ายภายในได้ไหม

    • ในบริบทของใบรับรองที่ออกโดย public CA คิดว่าคำถามนี้ไม่ค่อยมีความหมาย
      ต่างจากโดเมนตรงที่ private IP อย่าง 10.10.10.10 มีคนจำนวนมากเป็น "เจ้าของ" พร้อมกันอยู่
      ถ้าใช้พัฒนาภายใน ก็มีเครื่องมืออย่าง mkcert และถ้าเป็นทรัพยากรที่ใช้ร่วมกันในบริษัท ใบรับรอง TLS แบบอิงโดเมนจะสะดวกกว่า

    • ถ้าพิสูจน์ได้ว่า private key ของอุปกรณ์จะไม่มีทางรั่วไหลเลย ก็อาจลองทำกับ CA เดิมได้
      แต่สำหรับใบรับรองที่อยู่ภายใน ถ้ามีใครซื้ออุปกรณ์ไปแล้วดึง private key ออกมาได้ ปัญหาการเพิกถอนคีย์ของใบรับรองก็จะเกิดขึ้นทันที
      ดังนั้นถ้าเป็นอุปกรณ์ที่เชื่อถือได้ ทางที่ใช้ได้จริงคือ import ใบรับรองด้วยตนเองเพื่อเข้าใช้งานโดยไม่เจอข้อผิดพลาด หรือถ้ามีหลายอุปกรณ์ก็สร้าง CA เองเพื่อกระจายใบรับรอง
      ยังสามารถใช้เซิร์ฟเวอร์ ACME แบบโอเพนซอร์สเพื่อทำระบบออกใบรับรองอัตโนมัติภายในแบบเดียวกับ Let's Encrypt ได้ด้วย

    • ตั้ง DNS ให้ชี้ public server ก่อนเพื่อขอใบรับรอง แล้วหลังจากนั้นค่อยเปลี่ยน DNS ให้ลงไปยังที่อยู่ภายใน 192.168… และคัดลอกใบรับรองกับคีย์ไปใช้งาน
      สิ่งที่ต้องระวังคือเราเตอร์บางรุ่นอาจ blackhole คำตอบ DNS ที่ forward ไปยังที่อยู่ภายใน จึงควรทดสอบล่วงหน้า

    • คิดว่าเบราว์เซอร์ไม่ควรเมิน private network
      สำหรับผม private network ก็คือแค่เราเตอร์ในบ้าน แต่สำหรับคนอื่นมันอาจเป็นเครือข่ายที่ครอบคลุมทั้งโลกก็ได้

  • น่าสนใจที่ใบรับรองตัวอย่างไม่มีฟิลด์ subject
    เลยสงสัยว่าเป็นเพราะขอด้วย IP และมี DNS ระบุอยู่ใน SAN หรือไม่

    • ตามที่ทีม Let's Encrypt บอก จากนี้ไปมีแผนจะใช้ subject alternative names อย่างเดียวแทน subject common name
      เริ่มใช้ไปแล้วในโปรไฟล์ใบรับรองอายุสั้น 6 วัน ส่วนโปรไฟล์แบบ "คลาสสิก" อายุ 90 วันยังไม่ได้ใช้

  • มีคนพูดติดตลกว่าอาจถึงเวลาที่ช่องโหว่ CVE-2010-3170 จะกลับมาเป็นประเด็นอีกครั้ง

    • ถ้าใครไปเขียนตรรกะตรวจสอบ X.509 เอง ก็อาจยังมีช่องโหว่แบบนั้นหลงเหลืออยู่ได้ แต่ในทางปฏิบัติจะเล่นงานด้วยวิธีนี้ได้ก็ต้องมี CA ที่ทำงานผิดพลาดออกใบรับรองนั้นให้ก่อน ซึ่งมองว่าโอกาสค่อนข้างต่ำ

  • น่าเสียดายที่ใบรับรองสำหรับที่อยู่ IP จะออกผ่านวิธี DNS challenge ไม่ได้
    แต่ก็เข้าใจได้ว่าทำไม