คำอธิบายเกี่ยวกับใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์: การแทนที่รหัสผ่านด้วยการระบุตัวตนทางคริปโตกราฟี

รหัสผ่านแบบเดิมนั้นล้าสมัยแล้ว เครือข่ายของคุณพร้อมรับสิ่งใหม่มาแทนที่หรือยัง?

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

สำหรับองค์กรหลายแห่ง คำตอบที่ตรงไปตรงมาคือ “รหัสผ่าน” หรือ “คีย์ API” และทั้งสองอย่างนี้สามารถถูกขโมย ถูกหลอกลวง หรือถูกนำไปใช้ซ้ำโดยใครก็ตามที่ได้มาครอบครอง

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

สำรวจตัวเลือกใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์

ทำไมเรื่องนี้ถึงกลายเป็นเรื่องเร่งด่วนขึ้นมาทันที

นี่คือการเปลี่ยนแปลงที่ทำให้เกิดปัญหานี้ ตั้งแต่วันที่ 15 มิถุนายน 2026 เป็นต้นไป โปรแกรม Root ของ Chrome กำหนดให้ต้องใช้สิทธิ์การเข้าถึงแบบสาธารณะที่ออกใหม่เท่านั้น TLS ใบรับรองเซิร์ฟเวอร์จะต้องมีเฉพาะ EKU serverAuth เท่านั้น Mozilla, Apple และ Microsoft ได้นำนโยบายโปรแกรมรูทที่เข้ากันได้มาใช้ ซึ่งยุติการใช้ EKU clientAuth ในใบรับรองที่เชื่อถือได้สาธารณะ TLS ใบรับรองเซิร์ฟเวอร์

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

องค์กรใดก็ตามที่ยังคงใช้ใบรับรองแบบสองวัตถุประสงค์รุ่นเก่าอยู่ ถือว่าไม่ปฏิบัติตามข้อกำหนดแล้วในปัจจุบัน และความเสี่ยงจะยิ่งเพิ่มมากขึ้นหากปล่อยไว้โดยไม่แก้ไข เรื่องนี้ส่งผลกระทบต่อทุกคนที่ใช้การตรวจสอบสิทธิ์โดยใช้ใบรับรองสำหรับ...TLSรวมถึงการเข้าถึงแบบ Zero Trust, VPN, การเข้าถึงเครือข่าย Wi-Fi, อุปกรณ์ IoT, ระบบควบคุมอุตสาหกรรม หรือแพลตฟอร์มตลาดพลังงาน

ใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์ทำหน้าที่อะไรกันแน่

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

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

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

ประโยชน์หลักโดยสรุป

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

• การยืนยันตัวตนที่ทนทานต่อการหลอกลวง (Phishing) กุญแจส่วนตัวจะไม่ถูกส่งออกจากอุปกรณ์ ดังนั้นจึงไม่มีรหัสผ่านให้ขโมย นำไปใช้ซ้ำ หรือหลอกลวงได้
• รองรับ Chrome และโปรแกรม Root EKU สำหรับ ClientAuth ที่ออกแบบมาโดยเฉพาะ ซึ่งตรงตามข้อกำหนดของ CA/Browser Forum และ Root Store เพื่อให้คุณไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนโยบายที่เป็นต้นเหตุของเรื่องทั้งหมดนี้
• โครงสร้างลำดับชั้นที่ได้รับความไว้วางใจจากสาธารณชน ออกโดยหน่วยงานตรวจสอบสาธารณะของ SSL ที่ได้รับการรับรองจาก WebTrust PKIโดยไม่จำเป็นต้องแจกจ่ายรูทส่วนตัวไปยังสแต็กฝ่ายที่พึ่งพาของคุณ
• สามระดับการตรวจสอบความถูกต้อง IV, OV และ IV+OV (ผู้สนับสนุน) เพื่อให้ข้อมูลประจำตัวสอดคล้องกับนโยบายการระบุตัวตนของคุณและข้อกำหนดด้านกฎระเบียบใดๆ ที่คุณปฏิบัติตาม
• การเพิกถอนแบบละเอียด เพิกถอนใบรับรองเพียงใบเดียวในทันทีที่อุปกรณ์สูญหาย เลิกใช้งาน หรือถูกบุกรุก โดยไม่กระทบต่ออุปกรณ์อื่นๆ ในเครือข่ายของคุณ
• การออกเอกสารผ่าน API เป็นหลัก ปัจจุบันสามารถแก้ไขปัญหาในวงกว้างได้ผ่าน REST API ของ SSL และกำลังจะมีระบบอัตโนมัติ ACME และ SCEP/EST ตามมาในอนาคต

การจับคู่ข้อมูลประจำตัวกับกรณีการใช้งาน

การตรวจสอบตัวตนรายบุคคล (IV) ยืนยันตัวตนที่แท้จริงของบุคคลที่ระบุชื่อ ทำให้เหมาะสำหรับอุปกรณ์ของพนักงาน นโยบาย BYOD และการเข้าถึงปลายทางส่วนบุคคล การตรวจสอบตัวตนองค์กร (OV) ยืนยันการมีอยู่ตามกฎหมายของบริษัท ซึ่งเป็นสิ่งที่คุณต้องการสำหรับเซิร์ฟเวอร์ เครื่องเสมือน บัญชีบริการ และไคลเอ็นต์ API และสำหรับสถานการณ์ที่คุณต้องการทั้งสองอย่าง เช่น ผู้ใช้ที่มีสิทธิ์พิเศษ ผู้รับเหมา หรืออุตสาหกรรมที่มีการควบคุม ก็มี IV+OV (การตรวจสอบตัวตนผู้สนับสนุน) ซึ่งเชื่อมโยงตัวตนของบุคคลกับองค์กรผู้สนับสนุนไปพร้อมกัน

ความยืดหยุ่นนั้นมีความสำคัญ เพราะการยืนยันตัวตนของลูกค้าปรากฏในหลายที่มากกว่าที่คนส่วนใหญ่คิด:

ใช้กรณี	ระดับประกาศนียบัตร	เข้ากันได้กับ	หมายเหตุ :
mTLS / ความไว้วางใจเป็นศูนย์	OV / IV+OV	Nginx, Envoy, Istio, Kong, AWS API Gateway	ซึ่งกันและกัน TLSทั้งสองฝ่ายยืนยันตัวตนด้วย X.509
VPN (แบบใช้ใบรับรอง)	IV / OV / IV+OV	Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX	ขจัดปัญหาการใช้รหัสผ่าน VPN; ป้องกันการโจมตีแบบฟิชชิ่ง
Wi-Fi (802.1X / EAP-TLS)	เส้นเลือดดำ / รังไข่	Cisco ISE, Aruba ClearPass, Microsoft NPS	การบังคับใช้ NAC; ข้อมูลประจำตัวอยู่ในอุปกรณ์ ไม่ใช่ในรหัสผ่าน
IoT / การระบุตัวตนอุปกรณ์	OV	AWS IoT Core, Azure IoT Hub, โบรกเกอร์แบบกำหนดเอง	ใบรับรองต่ออุปกรณ์แต่ละชิ้น; สามารถเพิกถอนใบรับรองทีละชิ้นได้โดยไม่ต้องทำการแฟลชเฟิร์มแวร์ใหม่ให้กับอุปกรณ์ทั้งหมด
OT / SCADA / ICS	OV	Claroty, Nozomi, Dragos; สแต็กที่รองรับมาตรฐาน IEC 62443	ตรวจสอบความถูกต้องของ PLC, HMI และโหนดบันทึกข้อมูลในเครือข่าย OT
ตลาดพลังงาน NAESB	IV+OV	แพลตฟอร์มที่สอดคล้องกับ NAESB WEQ-12	ต้องมีข้อมูลประจำตัวสำหรับ OATI, PowerSecure และแพลตฟอร์ม EIS อื่นๆ
การตรวจสอบสิทธิ์ API Gateway	OV / IV+OV	Apigee, Kong, AWS API GW, Azure APIM	แทนที่คีย์ API และ JWT ด้วยข้อมูลประจำตัวบริการที่ผูกกับใบรับรอง

นอกเหนือจากกรณีการใช้งานเฉพาะเหล่านั้นแล้ว ใบรับรองเหล่านี้ยังใช้งานได้อย่างกว้างขวางในโครงสร้างพื้นฐานที่ทีมของคุณใช้งานอยู่แล้ว:

• TLS สแต็ค: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL และ mbedTLS.
• VPN และการเข้าถึงระยะไกล: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN และ WireGuard (ผ่านการตรวจสอบสิทธิ์ภายนอก)
• NAC และ 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS และ Juniper Access Control
• เกตเวย์ API: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management และ Apigee
• ICS และ OT: แพลตฟอร์มที่รองรับมาตรฐาน IEC 62443 รวมถึงเลเยอร์การค้นหาและการตรวจสอบสิทธิ์สินทรัพย์ใน Claroty, Nozomi Networks และ Dragos

การส่งใบรับรองออกไปให้ถึงที่

ไม่ว่าองค์กรของคุณจะต้องการออกใบรับรองด้วยวิธีใด SSL ก็มีช่องทางที่เหมาะสมให้เลือกใช้:

วิธี	สำหรับใคร	วิธีการทำงาน
ส่วนติดต่อผู้ใช้บนเว็บ (แดชบอร์ด ssl.com)	ผู้ดูแลระบบไอที การติดตั้งขนาดเล็ก การออกใบอนุญาตแบบครั้งเดียว	เข้าสู่ระบบ ssl.com เลือก Client Authentication เลือก Validation Level กรอกข้อมูลยืนยันให้ครบถ้วน สร้างและดาวน์โหลดใบรับรอง ไม่จำเป็นต้องเขียนโค้ด
REST API	DevOps, ไปป์ไลน์ CI/CD, การจัดเตรียมกลุ่มอุปกรณ์ขนาดใหญ่	การสั่งซื้อใบรับรองแบบโปรแกรม CSR การส่งและดาวน์โหลดผ่าน REST API ที่มีเอกสารรับรองของ SSL รองรับการออกบัตรจำนวนมากและการผสานรวมกับแพลตฟอร์มการจัดการระบบ
เอซีเอ็มอี / เอสซีพี / เอสทีเอสที	Enterprise MDM, ระบบอัตโนมัติตามมาตรฐาน IETF (อยู่ในระหว่างการวางแผน)	ระบบอัตโนมัติวงจรชีวิตแบบอิงตามโปรโตคอลผ่าน ACME (RFC 8555), SCEP และ EST (RFC 7030) อยู่ระหว่างการพัฒนา โปรดติดต่อฝ่ายขายเพื่อสอบถามรายละเอียดเกี่ยวกับกำหนดการและสิทธิ์การเข้าถึงก่อนใคร

วิธีการสั่งซื้อ

ใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์สามารถขอรับได้โดยตรงจาก SSL โดยไม่มีข้อผูกมัดขั้นต่ำ:

• บริการตนเอง. กำหนดค่าและสั่งซื้อออนไลน์.
• ธุรกิจขนาดใหญ่และปริมาณมาก ติดต่อทีมขายของ SSL สำหรับการกำหนดราคาตามปริมาณ การจัดการบัญชีเฉพาะ และ สพป-ขั้นตอนการเริ่มต้นใช้งานเฉพาะด้าน
• ลำดับชั้นส่วนตัวหรือความต้องการ EKU สองระบบ หากคุณต้องการโครงสร้างลำดับชั้นส่วนตัว โปรไฟล์ใบรับรองแบบกำหนดเอง หรือใบรับรอง EKU คู่ ส่วนตัวของ SSL PKI เทคโนโลยี (ใบรับรองส่วนบุคคลที่มีความน่าเชื่อถือสูง, เฉพาะเจาะจง) PKIและองค์กร PKI) คือเส้นทางที่ถูกต้อง ติดต่อฝ่ายขายเพื่อขอคำแนะนำ

บรรทัดด้านล่าง

การเปลี่ยนแปลง EKU ของ clientAuth ไม่ใช่แค่เรื่องทางเทคนิคเล็กน้อย แต่เป็นการผลักดันให้องค์กรต่างๆ แยกข้อมูลประจำตัวของเซิร์ฟเวอร์ออกจากข้อมูลประจำตัวของไคลเอ็นต์ และแทนที่รหัสผ่านและคีย์ API ด้วยสิ่งที่ไม่สามารถถูกหลอกลวงหรือนำไปใช้ซ้ำได้

SSL ดำเนินการเป็นหน่วยงานออกใบรับรองสาธารณะที่ได้รับการตรวจสอบโดย WebTrust มานานกว่า 20 ปีแล้ว และใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์ (Client Authentication Certificate) เป็นเส้นทางที่ตรงไปตรงมาและสอดคล้องกับกฎระเบียบสำหรับองค์กรใด ๆ ที่ต้องการการระบุตัวตนไคลเอ็นต์โดยเฉพาะในระดับขนาดใหญ่ ไม่ว่าจะเป็นการรักษาความปลอดภัยเครือข่าย Zero Trust กลุ่มอุปกรณ์ IoT หรือแพลตฟอร์มการซื้อขายที่อยู่ภายใต้การกำกับดูแลของ NAESB ก็ตาม

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

m ของคุณคือใครTLS ได้รับผลกระทบจากการยกเลิก clientAuth EKU หรือไม่? ตรวจสอบใบรับรองของคุณสำหรับ clientAuth EKU จากนั้นติดต่อ SSL เพื่อขอให้ย้ายไปใช้ใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์โดยเฉพาะ (หรือใบรับรองส่วนตัว) PKI (สำหรับใช้งานภายในเท่านั้น / ความต้องการ EKU คู่) ก่อนที่ใบรับรองปัจจุบันของคุณจะหมดอายุ: