Certificate authority

ผู้ออกใบรับรอง หรือ Certification authority (CA) เป็นหน่วยงานที่ออกใบรับรองดิจิทัลในการเข้ารหัส ซึ่งใบรับรองดิจิทัลรับรองความเป็นเจ้าของกุญแจสาธารณะโดยมีชื่อเรื่องของใบรับรอง มีการรับรองอนุญาตให้คนอื่นใช้งานได้ โดยขึ้นอยู่กับลายเซ็นหรือยืนยันตัวโดยการทำกุญแจส่วนตัว (private key) ที่สอดคล้องกับกุญแจสาธารณะ (public key) ที่ถูกรับรอง ในรูปแบบความสัมพันธ์ที่เชื่อถือได้ ผู้ออกใบรับรองเป็นบุคคลที่สามที่เชื่อถือได้ ซึ่งได้รับความเชื่อถือทั้งจากเจ้าของข้อมูลที่มีใบรับรองและผู้ที่ได้รับสิ่งที่มีใบรับรองนั้น รูปแบบของการรับรองอยู่บนมาตรฐาน X.509 หรือ EMV แผนของผู้ให้บริการเทคโนโลยีโครงสร้างพื้นฐานกุญแจสาธารณะ (Public Key Infrastructure, PKI) จำนวนมากจะแสดงตนว่าเป็นผู้ออกใบรับรองด้วย

ภาพรวม

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

ผู้ใช้บริการของผู้ออกใบรับรอง เป็นผู้ดูแลเซิร์ฟเวอร์ ซึ่งต้องการใบรับรองที่เซิร์ฟเวอร์ของพวกเขาจะนำเสนอให้แก่ผู้ใช้บริการได้ จ่ายให้กับผู้ออกใบรับรองในการออกใบรับรอง และลูกค้าของพวกเขาหวังว่าใบรับรองของผู้ออกใบรับรองจะถูกรวบรวมโดยเว็บเบราว์เซอร์ส่วนใหญ่ เพื่อที่จะให้การเชื่อมต่อปลอดภัยคือ เซิร์ฟเวอร์ซึ่งถูกรับรองทำงานได้อย่างราบรื่น จำนวนเว็บเบราว์เซอร์ อุปกรณ์อื่น ๆ และ แอปพลิเคชันซึงเชื่อถือผู้ออกใบรับรองโดยเฉพาะ จะถูกกล่าวถึงอย่างแพร่หลาย มอซิลลาซึ่งเป็นองค์กรที่แสวงผลกำไร ได้กระจายใบรับรองของผู้ออกใบรับรองกับผลิตภัณฑ์ของบริษัทไปอย่างแพร่หลาย ในขณะที่มอซิลลาพัฒนานโยบาย CA/Browser Forum ได้พัฒนาแนวทางสำหรับความน่าเชื่อถือของผู้ออกใบรับรองเช่นกัน ใบรับรองของผู้ออกใบรับรองใบเดียวอาจจะถูกใช้ร่วมกับหลาย ๆ ผู้ออกใบรับรอง และลูกค้าของพวกเขา ใบรับรอง root CA มักจะเป็นฐานที่จะออกใบรับรองกลาง ที่สามารถประยุกต์ตามความต้องการที่แตกต่างกัน

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

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

ผู้ให้บริการ

ธุรกิจผู้ออกใบรับรองทั่วโลก มีการแบ่งส่วนทั้งระดับชาติและระดับภูมิภาคซึ่งมีอำนาจเหนือตลาดทั่วไป เป็นเพราะการใช้งานใบรับรองดิจิทัลจำนวนมากเชื่อมโยงกฎหมายท้องถิ่น ซึ่งมีข้อบังคับ และการให้อำนาจวางแผนสำหรับผู้ออกใบรับรอง เช่น สำหรับผลเกี่ยวข้องทางกฎหมายลายเซ็นดิจิทัล อย่างไรก็ตามมีตลาดสำหรับใบรับรอง SSL ซึ่งเป็นใบรับรองใช้สำหรับการรักษาความปลอดภัยเว็บไซต์ ทีโดยส่วนใหญ่จัดขึ้นโดยบริษัทข้ามชาติจำนวนหนึ่ง ตลาดนี้มีอุปสรรคสำคัญในการเข้าถึงเนื่องจากข้อกำหนดทางเทคนิค ในขณะที่ไม่จำเป็นต้องทำตามกฎหมาย ผู้ให้บริการรายใหม่อาจเลือกที่จะได้รับการตรวจสอบรายปี ซึ่งจะถูกรวมอยู่ในรายการของเว็บเบราว์เซอร์ที่มีผู้รับรองที่น่าเชื่อถือ เช่น WebTrust สำหรับผู้ออกใบรับรองในอเมริกาเหนือ และ ETSI ในยุโรป ใบรับรอง root certificate มากกว่า 50 ใบที่เชื่อถือได้เป็นที่นิยมในเว็บเบราว์เซอร์ โดยบริษัท W3Techs ได้สำรวจตั้งแต่เดือนกุมภาพันธ์ พ.ศ. 2558 พบว่า

อันดับ	ผู้ออกใบรับรอง	การใช้งาน	ส่วนแบ่งการตลาด
1.	Comodo	6.6%	33.6%
2.	Symantec Group	6.5%	33.2%
3.	Go Daddy Group	2.6%	13.2%
4.	GlobalSign	2.2%	11.3%
5.	DigiCert	0.6%	2.9%

วันที่ 18 พฤศจิกายน พ.ศ. 2557 กลุ่มบริษัทและองค์กรที่ไม่แสวงผลกำไร รวมทั้ง the Electronic Frontier Foundation, Mozilla, Cisco และ Akamai ประกาศว่า "Let's encrypt" ผู้ออกใบรับรองที่ไม่แสวงผลกำไรรายใหม่วางแผนที่จะออกใบรับรอง TLS โดยไม่คิดค่าใช้จ่าย โดยรวมทั้งซอฟต์แวร์ที่ใช้สำหรับติดตั้งและบำรุงรักษาใบรับรอง Let's encrypt จะถูกดำเนินการโดยกลุ่มวิจัยการรักษาความปลอดภัยอินเทอร์เน็ต "Internet Security Research Group" ที่ถูกจัดตั้งขึ้นมาใหม่ในแคลิฟอร์เนีย ซึ่งใช้ประโยชน์จากการยกเว้นภาษีของรัฐบาลตามมาตรา 501 (c) (3) ในช่วงเวลาการประกาศ

การตรวจสอบโดเมน

ผู้ออกใบรับรองซึ่งออกกลุ่มใบรับรองที่ลูกค้าไว้วางใจสำหรับเซิร์ฟเวอร์อีเมล และเซิร์ฟเวอร์ HTTPS สาธารณะมักจะใช้เทคนิคที่เรียกว่า "การตรวจสอบโดเมน" ในการตรวจสอบผู้รับใบรับรอง การตรวจสอบโดเมนเกี่ยวข้องกับการส่งอีเมล ที่มีการรับรองโทเค็นหรือลิงก์ไปยังที่อยู่อีเมลที่รู้จักกัน ซึ่งดำเนินการรับผิดชอบสำหรับโดเมน ซึ่งอาจเป็นรายการที่อยู่อีเมลที่ติดต่อทางเทคนิคใน WHOIS entry ของโดเมน หรืออีเมลที่เกี่ยวกับการบริหารงาน เช่น โดเมน admin@, administrator@, webmaster@, hostmaster@ หรือ postmaster@ ผู้ออกใบรับรองบางรายอาจยอมรับการใช้ โดเมน root@, info@ หรือ support@ ทฤษฎีที่อยู่เบื้องหลังการตรวจสอบโดเมนก็คือมีเจ้าของโดเมนที่ถูกต้องเท่านั้นที่จะสามารถอ่านอีเมลที่ส่งไปยังที่อยู่ของผู้ดูแลระบบ

การตรวจสอบโดเมนประสบกับข้อจำกัดของการรักษาความปลอดภัยของโครงสร้างบางอย่าง โดยเฉพาะอย่างยิ่งมันมักจะเสี่ยงต่อการโดนโจมตีที่ช่วยให้ฝ่ายตรงข้ามจะสังเกตเห็นอีเมล การตรวจสอบโดเมนที่ส่งโดยผู้ออกใบรับรองรวมถึงการโจมตีโพรโทคอล DNS, TCP และ BGP หรือการประนีประนอมของเราเตอร์ (ซึ่งขาดการคุ้มครองการเข้ารหัสลับของ TLS/SSL) การโจมตีดังกล่าวเป็นไปทั้งบนเครืองข่ายที่ใกล้ผู้ออกใบรับรองหรือใกล้โดเมนเหยื่อเอง

ผู้ออกใบรับรองบางรายเสนอใบรับรอง Extended Validation (EV) เป็นทางเลือกที่เข้มงวดมากขึ้นในการตรวจสอบโดเมนใบรับรอง หนึ่งในข้อจำกัดของ EV เป็นวิธีการแก้จุดอ่อนของการตรวจสอบโดเมนจากการโจมตีที่ยังคงได้รับใบรับรอง โดยใบรับรองการตรวจสอบโดเมนสำหรับโดเมนของผู้เคราะห์ร้ายมีการปรับใช้ระหว่างการโจมตีที่เกิดขึ้น ซึ่งมีเพียงข้อแตกต่างที่สังเกตได้ให้กับผู้ใช้ที่ตกเป็นเหยื่อโดยจะแสดงเป็นแถบ HTTPS address สีน้ำเงิน มากกว่าจะเป็นสีเขียว ผู้ใช้น้อยคนนักจะมีแนวโน้มที่จะยอมรับข้อแตกต่างนี้ซึ่งเป็นสิ่งบ่งชี้การโจมตีที่กำลังดำเนินการอยู่

การ imprement การตรวจสอบโดเมนบางครั้งยังคงได้รับต้นตอของจุดอ่อนในการรักษาความปลอดภัย หนึ่งในตัวอย่างการวิจัยด้านการรักษาความปลอดภัยพบว่าผู้ไม่หวังดีจะได้รับใบรับรองสำหรับเว็บเมล เพราะว่าผู้ออกใบรับรองตั้งใจที่จะใช้อีเมลเช่นเดียวกันกับโดเมน .com แต่ไม่ใช่ทุกระบบเว็บเมลที่จะได้รับลิขสิทธิ์ชื่อผู้ใช้ "SSLCertificates" เพื่อป้องกันผู้ประสงค์ร้ายจากการลงทะเบียน

การออกใบรับรอง

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

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

ตัวอย่าง

การเข้ารหัสกุญแจสาธารณะสามารถนำมาใช้ในการเข้ารหัสข้อมูลที่สื่อสารกันระหว่าง 2 ฝ่าย ซึ่งจะเกิดขึ้นเมื่อเมื่อผู้ใช้เข้าสู่ทุกเว็บไซต์ที่ implement โพรโทคอลการรักษาความปลอดภัย HTTPS ในตัวอย่างนี้ให้เราคิดว่าผู้ใช้เข้าสู่ระบบ www.bank.example เพื่อทำธุรกรรมทางการเงิน เมื่อผู้ใช้เปิดหน้าแรก www.bank.example เขาจะได้รับกุญแจสาธารณะ พร้อมกับข้อมูลทั้งหมดที่แสดงบนหน้าเว็บเบราว์เซอร์ กุญแจสาธารณะสามารถนำมาใช้ในการเข้ารหัสข้อมูลจากผู้ใช้ไปยังเซิร์ฟเวอร์ แต่ขั้นตอนที่ปลอดภัยที่จะใช้ในโพรโทคอลที่กำหนดกุญแจที่สมมาตรกัน ข้อความในโพรโทคอลดังกล่าวเป็นรหัสลับพร้อมกับกุญแจสาธารณะ และมีเพียงเซิร์ฟเวอร์ของธนาคารเท่านั้นที่มีกุญแจสาธารณะในการอ่านข้อมูล การสื่อสารดำเนินการโดยใช้กุญแจที่สมมาตรกันใหม่ ดังนั้นเมื่อผู้ใช้ป้อนข้อมูลบางอย่างไปยังหน้าเพจของธนาคารและกด submit ส่งข้อมูลให้ธนาคารแล้ว ข้อมูลผู้ใช้จะถูกป้อนไปยังหน้าเพจซึ่งจะถูกเข้ารหัสโดยเว็บเบราว์เซอร์นั่นเอง ดังนั้นถึงแม้ว่าบางคนสามารถเข้าถึงข้อมูลที่ถูกสื่อสารจากผู้ใช้ไปยัง www.bank.example ดังนั้นคนดักจับข้อมูลจะไม่สามารถอ่านและถอดรหัสได้

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

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

การรักษาความปลอดภัย

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

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

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

ในการใช้งานขนาดใหญ่ Alice อาจไม่คุ้นเคยกับใบรับรองของ Bob เพราะอาจมีผู้ออกใบรับรองที่แตกต่างกัน ดังนั้นใบรับรองของ Bob ยังอาจรวมกุญแจสาธารณะของผู้ออกใบรับรองที่ลงนามโดย CA ที่ต่างกัน ซึ่ง Alice น่าจะรู้จัก กระบวนการนี้นำไปสู่การรับรองเป็นลำดับชั้น หรือโครงข่ายผู้ออกใบรับรองหรือ "ใบรับรองผู้ออกใบรับรอง"

รายการเพิกถอนสิทธิ

รายการเพิกถอนสิทธิ (ARL) เป็นรูปแบบของ CRL ที่มีใบรับรองออกไปยังผู้ออกใบรับรอง ตรงกันข้ามกับ CRLs ที่มีใบรับรองเพิกถอนบุคคล

องค์กรอุตสาหกรรม

• Certificate Authority Security Council (CASC) – ก่อตั้งขึ้นในปี พ.ศ. 2556 ในฐานะที่เป็นองค์กรที่สนับสนุนอุตสาหกรรม มุ่งเป้าไปยังปัญหาที่มีอยู่และให้ความรู้แก่ประชาชนเกี่ยวกับการรักษาความปลอดภัยอินเทอร์เน็ต สมาชิกผู้ก่อตั้งคือผู้ออกใบรับรองขนาดใหญ่ลำดับที่ 7

การโจมตีผู้ออกใบรับรอง

ถ้าผู้ออกใบรับรองสามารถโดนโจมตี ซึ่งจะทำให้ระบบทั้งหมดเกิดความเสียหาย แม้ว่าหน่วยงานทั้งหมดจะเชื่อถือผู้ออกใบรับรองที่โดนบุกรุกนั้น ยกตัวอย่าง กรณีใบรับรองสนับสนุนการโจมตีเช่น Eve จัดการบางอย่างให้ได้การรับรองจาก CA ซึ่งมาจากใบรับรองของเธอที่อ้างว่าเป็นของ Alice ใบรับรองจะแถลงต่อสาธารณะว่านี่เป็นของ Alice และอาจรวมข้อมูลอื่น ๆ ของ Alice ข้อมูลบางอย่างเกี่ยวกับ Alice เช่นนายจ้างของเธออาจจะจริง ซึ่งช่วยเพิ่มความน่าเชื่อถือของใบรับรอง อย่างไรก็ตาม Eve อาจมีข้อมูลกุญแจส่วนตัวของใบรับรองที่สำคัญทั้งหมด ซึ่ง Eve สามารถใช้ใบรับรองเพื่อทำการลงนามดิจิทัลในอีเมลและส่งไปให้ Bob เพื่อหลอก Bob ให้เชื่อว่าอีเมลนั้นเป็นของ Alice โดย Bob อาจตอบอีเมลที่ถูกเข้ารหัสนั้น และเชื่อว่าจะถูกอ่านโดน Alice ซึ่ง Eve สามารถถอดรหัสอีเมลนั้นมาอ่านได้โดยใช้กุญแจส่วนตัว การทำลายระบบของผู้ออกใบรับรอง ที่โด่งดังเช่น กรณีนี้เกิดในปี พ.ศ. 2544 เมื่อผู้ออกใบรับรอง VeriSign ได้ออกใบรับรองสองตัวให้แก่บุคคลผู้แทนของบริษัทไมโครซอฟท์ ใบรับรองนั้นมีชื่อว่า “Microsoft Corporation” ดังนั้นอาจถูกใช้เพื่อหลอกใครบางคนเพื่อให้เชื่อว่าเป็นการปรับปรุงซอฟต์แวร์ของไมโครซอฟท์ ซึ่งจริง ๆ แล้วไม่ใช่ การทุจริตนี้ถูกพบในต้นปี พ.ศ. 2544 ซึ่งไมโครซอฟท์ และ VeriSign ได้ทำขั้นตอนเพื่อลดผลกระทบของปัญหาดังกล่าว

ในปี พ.ศ. 2554 ใบรับรอง *.google.com ที่หลอกลวงซึ่งบริษัท Comodo และ DigiNotar ได้รับมานั้น มีการกล่าวหาว่ากระทำโดยแฮกเกอร์ชาวอิหร่าน โดยมีหลักฐานว่าใบรับรอง DigiNotar ที่ปลอมนั้นถูกใช้เพื่อการโจมตีแบบ man-in-the-middle ในอิหร่าน

ในปี พ.ศ. 2555 เป็นที่ทราบกันว่า Trustwave ได้ออกใบรับรองชั้นรองจากระดับ root เพื่อใช้ในการจัดการดักจับการส่งข้อมูล (man-in-the-middle) ในองค์กรที่เป็นที่ยอมรับ โดยดักจับการส่งโพรโทคอล SSL ของเครือข่ายภายในโดยใช้ใบรับรองนั้น

การออกแบบและพัฒนาโปรแกรมอย่างเปิดเผย

มีการพัฒนาซอฟต์แวร์ผู้ออกใบรับรองที่เป็นแบบโอเพนซอร์ซอยู่ โดยทั่ว ๆ ไปคือ ออกบริการที่จำเป็น, ยกเลิก และจัดการใบรับรองการลงนาม ตัวอย่างโปรแกรมที่เป็นโอเพนซอร์ซ:

• DogTag
• EJBCA
• gnoMint
• OpenCA
• OpenSSL, an SSL/TLS library มาพร้อมกับตัวช่วยอนุญาตในการใช้งานใบรับรองอย่างง่าย
• EasyRSA, OpenVPN's command line CA utilities ซึ่งใช้โพรโทคอล OpenSSL
• r509
• TinyCA, ซึ่งเป็น perl gui ในส่วนบนของมอดูล CPAN
• XCA
• Automated Certificate Management Environment (ACME), ให้โพรโทคอลการเข้ารหัสเพื่อการสื่อสารระหว่างผู้ออกใบรับรองและเซิร์ฟเวอร์ ให้การเข้ารหัสแบบ node-acme, Node.js ของ ACME, และการตรวจดูการเข้ารหัส, พื้นฐานจากภาษาไพทอนของการจัดการเซิร์ฟเวอร์ใบรับรองโดยใช้โพรโทคอล ACME

อ้างอิง

1. "Mozilla Included CA Certificate List — Mozilla". Mozilla.org. จากแหล่งเดิมเมื่อ 2013-08-04. สืบค้นเมื่อ 2014-06-11.
2. Zakir Durumeric; James Kasten; Michael Bailey; J. Alex Halderman (12 September 2013). "Analysis of the HTTPS Certificate Ecosystem" (PDF). The Internet Measurement Conference. SIGCOMM. เก็บ (PDF) จากแหล่งเดิมเมื่อ 22 December 2013. สืบค้นเมื่อ 20 December 2013.
3. "webtrust". webtrust. จากแหล่งเดิมเมื่อ 2013-08-18. สืบค้นเมื่อ 2013-03-02.
4. Kirk Hall (April 2013). "Standards and Industry Regulations Applicable to Certification Authorities" (PDF). Trend Micro. (PDF) จากแหล่งเดิมเมื่อ 2016-03-04. สืบค้นเมื่อ 2014-06-11.
5. "Let's Encrypt: Delivering SSL/TLS Everywhere" (Press release). Let's Encrypt. จากแหล่งเดิมเมื่อ 2014-11-18. สืบค้นเมื่อ 2014-11-20.
6. "About". Let's Encrypt. จากแหล่งเดิมเมื่อ 2015-06-10. สืบค้นเมื่อ 2015-06-07.
7. "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.3" (PDF). (PDF) จากแหล่งเดิมเมื่อ 2015-03-23. สืบค้นเมื่อ 2015-03-20.
8. "CA/Forbidden or Problematic Practices - MozillaWiki". wiki.mozilla.org (ภาษาอังกฤษ). จากแหล่งเดิมเมื่อ 2017-07-21. สืบค้นเมื่อ 2017-07-06.
9. "SSL FAQ - Frequently Asked Questions - Rapid SSL". www.rapidssl.com. จากแหล่งเดิมเมื่อ 2015-02-06.
10. "Responsibilities of Certificate Authority". จากแหล่งเดิมเมื่อ 2015-02-12. สืบค้นเมื่อ 2015-02-12.
11. "PKI". Network World. IDG Network World. 17 January 2000. pp. 55–56.
12. Moti Yung; Markus Jakobsson; Jianying Zhou, บ.ก. (June 2004). Applied Cryptography and Network Security. Second International Conference, ACNS.
13. Behr, Kevin (2006). The Shortcut Guide to Managing Certificate Lifecycles. Real-Time Publisher. ISBN 9781931491594.
14. "Electronic Signatures and Records" (PDF). (PDF) จากแหล่งเดิมเมื่อ 2016-03-04. สืบค้นเมื่อ 2014-08-28.
15. "Certificate transparency". จากแหล่งเดิมเมื่อ 2013-11-01. สืบค้นเมื่อ 2013-11-03.
16. "Certificate transparency". Internet Engineering Task Force. จากแหล่งเดิมเมื่อ 2013-11-22. สืบค้นเมื่อ 2013-11-03.
17. . Network World. February 14, 2013. คลังข้อมูลเก่า เก็บจาก แหล่งเดิม เมื่อ July 28, 2013.
18. "Major Certificate Authorities Unite In The Name Of SSL Security". Dark Reading. February 14, 2013. คลังข้อมูลเก่า เก็บจาก แหล่งเดิม เมื่อ April 10, 2013.
19. "CA-2001-04". Cert.org. จากแหล่งเดิมเมื่อ 2013-11-02. สืบค้นเมื่อ 2014-06-11.
20. Microsoft, Inc. (2007-02-21). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". จากแหล่งเดิมเมื่อ 2011-10-26. สืบค้นเมื่อ 2011-11-09.
21. Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack". Ars Technica. จากแหล่งเดิมเมื่อ 29 August 2011. สืบค้นเมื่อ 2011-09-01.
22. Bright, Peter (2011-08-30). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. จากแหล่งเดิมเมื่อ 2011-09-12. สืบค้นเมื่อ 2011-09-01.
23. Leyden, John (2011-09-06). "Inside 'Operation Black Tulip': DigiNotar hack analysed". The Register. จากแหล่งเดิมเมื่อ 2017-07-03.
24. "Trustwave issued a man-in-the-middle certificate". The H Security. 2012-02-07. จากแหล่งเดิมเมื่อ 2012-03-13. สืบค้นเมื่อ 2012-03-14.

แหล่งข้อมูลอื่น

• How secure is HTTPS today? How often is it attacked?, Electronic Frontier Foundation. (25 October 2011)