ในด้านการเข้ารหัสลับหน่วยงานออกใบรับรองหรือหน่วยงานรับรอง ( CA ) คือหน่วยงานที่จัดเก็บ ลงนาม และออกใบรับรองดิจิทัลใบรับรองดิจิทัลรับรองความเป็นเจ้าของกุญแจสาธารณะโดยผู้ที่ระบุชื่อในใบรับรอง ซึ่งทำให้ผู้อื่น (ฝ่ายที่เชื่อถือ) สามารถเชื่อถือลายเซ็นหรือการยืนยันเกี่ยวกับกุญแจส่วนตัวที่สอดคล้องกับกุญแจสาธารณะที่ได้รับการรับรองได้ CA ทำหน้าที่เป็นบุคคลที่สามที่น่าเชื่อถือ—ซึ่งได้รับความไว้วางใจทั้งจากผู้เป็นเจ้าของใบรับรองและจากฝ่ายที่เชื่อถือใบรับรอง^{[ 1 ]}รูปแบบของใบรับรองเหล่านี้ถูกกำหนดโดยมาตรฐาน X.509หรือEMV

การใช้งานทั่วไปอย่างหนึ่งของหน่วยงานออกใบรับรองคือการลงนามในใบรับรองที่ใช้ในHTTPSซึ่งเป็นโปรโตคอลการท่องเว็บที่ปลอดภัยสำหรับเวิลด์ไวด์เว็บ การใช้งานทั่วไปอีกอย่างหนึ่งคือการออกบัตรประจำตัวประชาชนโดยรัฐบาลของประเทศต่างๆ เพื่อใช้ในการลงนามเอกสารทางอิเล็กทรอนิกส์^{[ 2 ]}

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

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

นอกจาก CA เชิงพาณิชย์แล้ว องค์กรไม่แสวงหาผลกำไรบางแห่งยังออกใบรับรองดิจิทัลที่น่าเชื่อถือต่อสาธารณะโดยไม่คิดค่าใช้จ่าย เช่นLet's Encrypt นอกจากนี้ บริษัทผู้ให้บริการ คลาวด์คอมพิวติ้ง และเว็บโฮสติ้ง ขนาดใหญ่บางแห่งก็เป็น CA ที่น่าเชื่อถือต่อสาธารณะและออกใบรับรองให้กับบริการที่โฮสต์อยู่บนโครงสร้างพื้นฐานของตน เช่นIBM Cloud , Amazon Web Services , CloudflareและGoogle Cloud Platform

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

ธนาคารพาณิชย์ที่ออก บัตรชำระเงิน EMVอยู่ภายใต้การกำกับดูแลของหน่วยงานออกใบรับรอง EMV ^{[ 5 ]}ซึ่งเป็นระบบการชำระเงินที่ส่งต่อธุรกรรมการชำระเงินที่เริ่มต้น ณ จุดขาย ( POS ) ไปยังธนาคารผู้ออกบัตรเพื่อโอนเงินจากบัญชีธนาคารของผู้ถือบัตรไปยังบัญชีธนาคารของผู้รับชำระเงินบัตรชำระเงิน แต่ละใบ จะแสดงพร้อมกับข้อมูลบัตรและใบรับรองผู้ออกบัตรต่อ POS ใบรับรองผู้ออกบัตรได้รับการลงนามโดยใบรับรอง EMV CA POS จะดึงคีย์สาธารณะของ EMV CA จากที่เก็บข้อมูล ตรวจสอบความถูกต้องของใบรับรองผู้ออกบัตรและความถูกต้องของบัตรชำระเงินก่อนที่จะส่งคำขอชำระเงินไปยังระบบการชำระเงิน

โดยทั่วไปแล้วเบราว์เซอร์และไคลเอนต์ประเภทอื่นๆ จะอนุญาตให้ผู้ใช้เพิ่มหรือลบใบรับรอง CA ได้ตามต้องการ ในขณะที่ใบรับรองเซิร์ฟเวอร์มักมีอายุการใช้งานค่อนข้างสั้น ใบรับรอง CA จะได้รับการขยายเวลาออกไปอีก^{[ 6 ]}ดังนั้น สำหรับเซิร์ฟเวอร์ที่เข้าเยี่ยมชมซ้ำๆ การนำเข้าและเชื่อถือใบรับรอง CA ที่ออกให้จึงมีโอกาสเกิดข้อผิดพลาดน้อยกว่าการยืนยันข้อยกเว้นด้านความปลอดภัยทุกครั้งที่มีการต่ออายุใบรับรองของเซิร์ฟเวอร์

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

ในระดับโลก ธุรกิจการออกใบรับรองดิจิทัลมีความกระจัดกระจาย โดยผู้ให้บริการระดับชาติหรือระดับภูมิภาคครองตลาดในพื้นที่ของตนเอง เนื่องจากหลายการใช้งานของใบรับรองดิจิทัล เช่น ลายเซ็นดิจิทัลที่มีผลผูกพันทางกฎหมายนั้น เกี่ยวข้องกับกฎหมาย ข้อบังคับ และโครงการรับรองมาตรฐานสำหรับหน่วยงานออกใบรับรองในแต่ละท้องถิ่น

อย่างไรก็ตาม ตลาดสำหรับใบรับรองเซิร์ฟเวอร์ TLS/SSL ที่ได้รับความไว้วางใจทั่วโลก ส่วนใหญ่ถูกครอบครองโดยบริษัทข้ามชาติจำนวนน้อย ตลาดนี้มีอุปสรรคสำคัญในการเข้าสู่ตลาดเนื่องจากข้อกำหนดทางเทคนิค^{[ 7 ]}แม้ว่าจะไม่มีข้อกำหนดทางกฎหมาย แต่ผู้ให้บริการรายใหม่อาจเลือกที่จะเข้ารับการตรวจสอบความปลอดภัยประจำปี (เช่นWebTrust ^{[ 8 ]}สำหรับหน่วยงานออกใบรับรองในอเมริกาเหนือและETSIในยุโรป^{[ 9 ]} ) เพื่อให้ได้รับการรวมเป็นรากที่เชื่อถือได้โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ

ณ วันที่ 24 สิงหาคม 2563 ใบรับรองราก 147 ใบ ซึ่งเป็นตัวแทนของ 52 องค์กร ได้รับความไว้วางใจใน^เว็บเบราว์เซอร์Mozilla Firefox ^{[ 10 ]}ใบรับรองราก 168 ใบ ซึ่งเป็นตัวแทนของ 60 องค์กร ได้รับความไว้วางใจโดยmacOS [ ^{11 ]}และใบรับรองราก 255 ใบ ซึ่งเป็นตัวแทนของ 101 องค์กร ได้รับความไว้วางใจโดยMicrosoft Windows [ ^{12 ] ณ} ระบบปฏิบัติการ Android 4.2 (Jelly Bean) ปัจจุบัน Android มี CA มากกว่า 100 รายการ ซึ่งได้รับการอัปเดตในแต่ละเวอร์ชัน^{[ 13 ]}

เมื่อวันที่ 18 พฤศจิกายน 2014 กลุ่มบริษัทและองค์กรไม่แสวงหาผลกำไร ซึ่งรวมถึงElectronic Frontier Foundation , Mozilla, Cisco และ Akamai ได้ประกาศเปิดตัวLet's Encryptซึ่งเป็นหน่วยงานออกใบรับรองที่ไม่แสวงหาผลกำไรที่ให้ บริการ ใบรับรอง X.509 ที่ตรวจสอบโดเมนได้ฟรี รวมถึงซอฟต์แวร์ที่ช่วยให้สามารถติดตั้งและบำรุงรักษาใบรับรองได้^{[ 14 ]} Let's Encrypt ดำเนินการโดยInternet Security Research Group ที่เพิ่งก่อตั้งขึ้นใหม่ ซึ่งเป็นองค์กรไม่แสวงหาผลกำไรในแคลิฟอร์เนียที่ได้รับการยกเว้นภาษีของรัฐบาลกลาง^{[ 15 ]}

ตามรายงานของNetcraftในเดือนพฤษภาคม 2015 มาตรฐานอุตสาหกรรมสำหรับการตรวจสอบใบรับรอง TLS ที่ใช้งานอยู่ระบุว่า "แม้ว่าระบบนิเวศ [TLS] ทั่วโลกจะมีการแข่งขันสูง แต่ก็ถูกครอบงำโดย CA รายใหญ่เพียงไม่กี่ราย — หน่วยงานออกใบรับรองสามแห่ง (Symantec, Comodo, GoDaddy) คิดเป็นสามในสี่ของใบรับรอง [TLS] ที่ออกทั้งหมดบนเว็บเซิร์ฟเวอร์ที่เปิดเผยต่อสาธารณะ ตำแหน่งสูงสุดตกเป็นของ Symantec (หรือ VeriSign ก่อนที่จะถูกซื้อโดย Symantec) นับตั้งแต่การสำรวจ [ของเรา] เริ่มต้นขึ้น โดยปัจจุบันคิดเป็นสัดส่วนเกือบหนึ่งในสามของใบรับรองทั้งหมด เพื่อแสดงให้เห็นถึงผลกระทบของวิธีการที่แตกต่างกัน ในบรรดาไซต์ที่มีการใช้งานมากที่สุดหนึ่งล้านแห่ง Symantec ออกใบรับรองที่ถูกต้องและเชื่อถือได้ถึง 44% ซึ่งมากกว่าส่วนแบ่งการตลาดโดยรวมอย่างมีนัยสำคัญ" ^{[ 16 ]}

ณ เดือนกรกฎาคม พ.ศ. 2567 บริษัทสำรวจ W3Techs ซึ่งรวบรวมสถิติการใช้งานหน่วยงานออกใบรับรองใน 10 ล้านอันดับแรกของ Alexaและ 1 ล้านอันดับแรกของ Tranco ได้ระบุหน่วยงานออกใบรับรองที่ใหญ่ที่สุด 5 อันดับแรกตามส่วนแบ่งการใช้งานโดยรวมดังต่อไปนี้^{[ 17 ]}

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

หน่วยงานออกใบรับรองหลายแห่งยังเสนอ ใบรับรอง แบบ Extended Validation (EV) เป็นทางเลือกที่เข้มงวดกว่าใบรับรองแบบ Domain Validation การตรวจสอบแบบ Extended Validation มีจุดประสงค์เพื่อตรวจสอบไม่เพียงแค่การควบคุมชื่อโดเมนเท่านั้น แต่ยังรวมถึงข้อมูลระบุตัวตนเพิ่มเติมที่จะรวมอยู่ในใบรับรองด้วย เบราว์เซอร์บางตัวจะแสดงข้อมูลระบุตัวตนเพิ่มเติมนี้ในกรอบสีเขียวในแถบ URL ข้อจำกัดอย่างหนึ่งของ EV ในฐานะวิธีการแก้ปัญหาจุดอ่อนของ Domain Validation คือ ผู้โจมตียังคงสามารถได้รับใบรับรองแบบ Domain Validation สำหรับโดเมนของเหยื่อ และนำไปใช้ในการโจมตีได้ หากเกิดเหตุการณ์เช่นนั้น ความแตกต่างที่ผู้ใช้ที่เป็นเหยื่อจะสังเกตเห็นได้คือ การไม่มีแถบสีเขียวที่มีชื่อบริษัท มีข้อสงสัยว่าผู้ใช้จะรับรู้ถึงการไม่มีแถบนี้ว่าเป็นสัญญาณของการโจมตีหรือไม่ การทดสอบโดยใช้Internet Explorer 7ในปี 2009 แสดงให้เห็นว่าผู้ใช้ไม่สังเกตเห็นการไม่มีคำเตือน EV ของ IE7 อย่างไรก็ตาม เบราว์เซอร์รุ่นใหม่กว่าของ Microsoft อย่างEdge Legacyแสดงความแตกต่างระหว่าง EV และใบรับรองแบบ Domain Validation ได้มากกว่าอย่างเห็นได้ชัด โดยใบรับรองแบบ Domain Validation จะมีรูปแม่กุญแจสีเทาโปร่ง

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

หนึ่งในเทคนิคการตรวจสอบความถูกต้องของโดเมนที่พบบ่อยที่สุดคือการส่งอีเมลที่มีโทเค็นการตรวจสอบสิทธิ์หรือลิงก์ไปยังที่อยู่อีเมลที่น่าจะรับผิดชอบด้านการบริหารโดเมน ซึ่งอาจเป็นที่อยู่อีเมลติดต่อทางเทคนิคที่ระบุไว้ใน รายการ WHOIS ของโดเมน หรืออีเมลผู้ดูแลระบบ เช่นadmin@ , administrator@ , webmaster@ , hostmaster@หรือpostmaster@ของโดเมน^{[ 18 ] [ 19 ]} หน่วยงานออกใบรับรองบางแห่งอาจยอมรับการยืนยันโดยใช้root@ , info@หรือsupport@ในโดเมน^{[ 20 ]} ทฤษฎีเบื้องหลังการตรวจสอบความถูกต้องของโดเมนคือ มีเพียงเจ้าของโดเมนที่ถูกต้องตามกฎหมายเท่านั้นที่จะสามารถอ่านอีเมลที่ส่งไปยังที่อยู่อีเมลผู้ดูแลระบบเหล่านี้ได้

การใช้งานการตรวจสอบความถูกต้องของโดเมนบางครั้งอาจเป็นแหล่งที่มาของช่องโหว่ด้านความปลอดภัย ในกรณีหนึ่ง นักวิจัยด้านความปลอดภัยแสดงให้เห็นว่าผู้โจมตีสามารถได้รับใบรับรองสำหรับ เว็บไซต์ เว็บเมลได้เนื่องจาก CA ยินดีที่จะใช้ที่อยู่อีเมลเช่น[email protected]สำหรับ domain.com แต่ระบบเว็บเมลบางระบบไม่ได้สงวนชื่อผู้ใช้ "ssladmin" ไว้เพื่อป้องกันไม่ให้ผู้โจมตีลงทะเบียน^{[ 21 ]}

ก่อนปี 2011 ไม่มีรายการมาตรฐานของที่อยู่อีเมลที่สามารถใช้สำหรับการตรวจสอบโดเมน ดังนั้นจึงไม่ชัดเจนสำหรับผู้ดูแลระบบอีเมลว่าต้องสงวนที่อยู่อีเมลใดบ้าง เวอร์ชันแรกของ ข้อกำหนดพื้นฐานของ CA/Browser Forumซึ่งนำมาใช้ในเดือนพฤศจิกายน 2011 ได้ระบุรายการที่อยู่อีเมลดังกล่าวไว้ ทำให้ผู้ให้บริการอีเมลสามารถสงวนที่อยู่อีเมลเหล่านั้นไว้สำหรับการใช้งานของผู้ดูแลระบบได้ แม้ว่าข้อควรระวังดังกล่าวจะยังไม่แพร่หลายก็ตาม ในเดือนมกราคม 2015 ชายชาวฟินแลนด์คนหนึ่งได้ลงทะเบียนชื่อผู้ใช้ "hostmaster" ในMicrosoft Live เวอร์ชันภาษาฟินแลนด์ และสามารถได้รับใบรับรองที่ตรวจสอบโดเมนสำหรับ live.fi ได้ แม้ว่าจะไม่ได้เป็นเจ้าของชื่อโดเมนก็ตาม^{[ 22 ]}

CA ออกใบรับรองดิจิทัลที่มีคีย์สาธารณะและข้อมูลประจำตัวของเจ้าของ คีย์ส่วนตัวที่ตรงกันจะไม่เปิดเผยต่อสาธารณะ แต่จะถูกเก็บเป็นความลับโดยผู้ใช้ปลายทางที่สร้างคู่คีย์ ใบรับรองนี้ยังเป็นการยืนยันหรือตรวจสอบโดย CA ว่าคีย์สาธารณะที่อยู่ในใบรับรองนั้นเป็นของบุคคล องค์กร เซิร์ฟเวอร์ หรือหน่วยงานอื่นที่ระบุไว้ในใบรับรอง หน้าที่ของ CA ในโครงการดังกล่าวคือการตรวจสอบข้อมูลประจำตัวของผู้สมัคร เพื่อให้ผู้ใช้และฝ่ายที่พึ่งพาสามารถเชื่อถือข้อมูลในใบรับรองที่ออกได้ CA ใช้มาตรฐานและการทดสอบที่หลากหลายเพื่อดำเนินการดังกล่าว โดยพื้นฐานแล้ว หน่วยงานออกใบรับรองมีหน้าที่รับผิดชอบในการกล่าวว่า "ใช่ บุคคลนี้เป็นคนที่พวกเขาบอกว่าเป็น และเรา CA รับรองสิ่งนั้น" ^{[ 23 ]}

หากผู้ใช้เชื่อถือ CA และสามารถตรวจสอบลายเซ็นของ CA ได้ พวกเขาก็สามารถสันนิษฐานได้ว่าคีย์สาธารณะบางอย่างเป็นของผู้ที่ระบุไว้ในใบรับรองจริง ๆ^{[ 24 ]}

การเข้ารหัสแบบกุญแจสาธารณะสามารถใช้ในการเข้ารหัสข้อมูลที่สื่อสารระหว่างสองฝ่ายได้ โดยทั่วไปแล้วจะเกิดขึ้นเมื่อผู้ใช้ล็อกอินเข้าสู่เว็บไซต์ใดๆ ที่ใช้ โปรโตคอล HTTP Secureในตัวอย่างนี้ สมมติว่าผู้ใช้ล็อกอินเข้าสู่หน้าแรกของธนาคาร www.bank.example เพื่อทำธุรกรรมธนาคารออนไลน์เมื่อผู้ใช้เปิดหน้าแรก www.bank.example พวกเขาจะได้รับกุญแจสาธารณะพร้อมกับข้อมูลทั้งหมดที่เบราว์เซอร์แสดง กุญแจสาธารณะสามารถใช้ในการเข้ารหัสข้อมูลจากไคลเอนต์ไปยังเซิร์ฟเวอร์ได้ แต่ขั้นตอนที่ปลอดภัยคือการใช้ในโปรโตคอลที่กำหนดกุญแจเข้ารหัสแบบสมมาตรที่ใช้ร่วมกันชั่วคราว ข้อความในโปรโตคอลการแลกเปลี่ยนกุญแจดังกล่าวสามารถเข้ารหัสด้วยกุญแจสาธารณะของธนาคารได้ในลักษณะที่เฉพาะเซิร์ฟเวอร์ของธนาคารเท่านั้นที่มีกุญแจส่วนตัวเพื่ออ่านข้อความเหล่านั้น^{[ 25 ]}

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

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

นี่คือสิ่งที่กลไกหน่วยงานออกใบรับรองมีจุดประสงค์เพื่อป้องกัน หน่วยงานออกใบรับรอง (CA) คือองค์กรที่จัดเก็บคีย์สาธารณะและเจ้าของคีย์เหล่านั้น และทุกฝ่ายในการสื่อสารจะเชื่อถือองค์กรนี้ (และรู้จักคีย์สาธารณะขององค์กรนี้) เมื่อเว็บเบราว์เซอร์ของผู้ใช้ได้รับคีย์สาธารณะจาก www.bank.example มันจะได้รับลายเซ็นดิจิทัลของคีย์ (พร้อมข้อมูลเพิ่มเติมบางอย่าง ใน ใบรับรอง X.509 ที่เรียกว่า ) เบราว์เซอร์มีคีย์สาธารณะของ CA อยู่แล้ว และด้วยเหตุนี้จึงสามารถตรวจสอบลายเซ็น เชื่อถือใบรับรองและคีย์สาธารณะในนั้นได้ เนื่องจาก www.bank.example ใช้คีย์สาธารณะที่หน่วยงานออกใบรับรองรับรอง ดังนั้น www.bank.example ปลอมจึงสามารถใช้คีย์สาธารณะเดียวกันได้เท่านั้น เนื่องจาก www.bank.example ปลอมไม่รู้จักคีย์ส่วนตัวที่เกี่ยวข้อง จึงไม่สามารถสร้างลายเซ็นที่จำเป็นในการตรวจสอบความถูกต้องได้^{[ 26 ]}

เป็นการยากที่จะรับประกันความถูกต้องของการจับคู่ระหว่างข้อมูลและเอนทิตีเมื่อข้อมูลถูกส่งไปยัง CA (อาจผ่านเครือข่ายอิเล็กทรอนิกส์) และเมื่อมีการนำเสนอข้อมูลประจำตัวของบุคคล/บริษัท/โปรแกรมที่ขอใบรับรองเช่นกัน นี่คือเหตุผลที่ CA เชิงพาณิชย์มักใช้เทคนิคการตรวจสอบความถูกต้องหลายวิธีร่วมกัน ซึ่งรวมถึงการใช้ประโยชน์จากหน่วยงานของรัฐ โครงสร้างพื้นฐานการชำระเงิน ฐานข้อมูลและบริการของบุคคลที่สาม และวิธีการวิเคราะห์แบบกำหนดเอง ในบางระบบขององค์กรสามารถใช้ รูปแบบการตรวจสอบความถูกต้องในท้องถิ่น เช่น Kerberos เพื่อขอรับใบรับรอง ซึ่งในทางกลับกันสามารถนำไปใช้โดยบุคคลภายนอกที่พึ่งพาได้ ในบางกรณี ทนายความรับรองเอกสารจำเป็นต้องรู้จักบุคคลที่มีลายเซ็นที่ได้รับการรับรองเป็นการส่วนตัว ซึ่งเป็นมาตรฐานที่สูงกว่าที่ CA หลายแห่งทำได้ ตาม โครงร่าง ของสมาคมเนติบัณฑิตอเมริกันเกี่ยวกับการจัดการธุรกรรมออนไลน์ ประเด็นหลักของกฎหมายของรัฐบาลกลางและรัฐของสหรัฐอเมริกาที่ตราขึ้นเกี่ยวกับลายเซ็นดิจิทัลคือ "เพื่อป้องกันกฎระเบียบในท้องถิ่นที่ขัดแย้งและเป็นภาระมากเกินไป และเพื่อสร้างความชัดเจนว่าเอกสารอิเล็กทรอนิกส์เป็นไปตามข้อกำหนดดั้งเดิมที่เกี่ยวข้องกับเอกสารกระดาษ" นอกจากนี้ กฎหมาย E-Sign ของสหรัฐอเมริกาและรหัส UETA ที่แนะนำ^{[ 27 ]}ช่วยให้มั่นใจได้ว่า:

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

แม้จะมีมาตรการรักษาความปลอดภัยที่ดำเนินการเพื่อตรวจสอบตัวตนของบุคคลและบริษัทอย่างถูกต้อง แต่ก็ยังมีความเสี่ยงที่ CA เดียวจะออกใบรับรองปลอมให้กับผู้แอบอ้าง นอกจากนี้ยังสามารถลงทะเบียนบุคคลและบริษัทที่มีชื่อเดียวกันหรือคล้ายกันมาก ซึ่งอาจนำไปสู่ความสับสน เพื่อลดอันตรายนี้โครงการริเริ่มความโปร่งใสของใบรับรองจึงเสนอให้ตรวจสอบใบรับรองทั้งหมดในบันทึกสาธารณะที่ไม่สามารถปลอมแปลงได้ ซึ่งอาจช่วยป้องกันการหลอกลวง ได้ ^{[ 28 ] [ 29 ]}

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

ใบรับรองอาจถูกเพิกถอนก่อนหมดอายุ ซึ่งบ่งชี้ว่าใบรับรองนั้นไม่ถูกต้องอีกต่อไป หากไม่มีการเพิกถอน ผู้โจมตีจะสามารถใช้ประโยชน์จากใบรับรองที่ถูกบุกรุกหรือออกผิดพลาดดังกล่าวได้จนกว่าจะหมดอายุ^{[ 30 ]}ดังนั้น การเพิกถอนจึงเป็นส่วนสำคัญของโครงสร้างพื้นฐานกุญแจสาธารณะ^{[ 31 ]}การเพิกถอนจะดำเนินการโดย CA ที่ออกใบรับรอง ซึ่งจะสร้าง คำแถลง การเพิกถอนที่ได้รับการรับรองทางคริปโตกราฟี^{[ 32 ]}

สำหรับการแจกจ่ายข้อมูลการเพิกถอนให้กับไคลเอนต์ ความทันท่วงทีของการค้นพบการเพิกถอน (และด้วยเหตุนี้จึงเป็นช่วงเวลาที่ผู้โจมตีสามารถใช้ประโยชน์จากใบรับรองที่ถูกบุกรุกได้) จะต้องแลกเปลี่ยนกับการใช้ทรัพยากรในการสอบถามสถานะการเพิกถอนและข้อกังวลด้านความเป็นส่วนตัว^{[ 33 ]}หากข้อมูลการเพิกถอนไม่พร้อมใช้งาน (ไม่ว่าจะเกิดจากอุบัติเหตุหรือการโจมตี) ไคลเอนต์จะต้องตัดสินใจว่าจะใช้fail-hardและถือว่าใบรับรองนั้นถูกเพิกถอน (ซึ่งจะทำให้ความพร้อมใช้งาน ลดลง ) หรือจะใช้fail-softและถือว่าใบรับรองนั้นยังไม่ถูกเพิกถอน (และอนุญาตให้ผู้โจมตีหลีกเลี่ยงการเพิกถอนได้) ^{[ 34 ]}

เนื่องจากค่าใช้จ่ายในการตรวจสอบการเพิกถอนและผลกระทบต่อความพร้อมใช้งานจากบริการระยะไกลที่อาจไม่น่าเชื่อถือเว็บเบราว์เซอร์จึงจำกัดการตรวจสอบการเพิกถอนที่จะดำเนินการ และจะล้มเหลวแบบอ่อนในกรณีที่ดำเนินการ^{[ 35 ]}รายการเพิกถอนใบรับรองมีค่าใช้จ่ายด้านแบนด์วิดท์สูงเกินไปสำหรับการใช้งานเป็นประจำ และโปรโตคอลสถานะใบรับรองออนไลน์ก่อให้เกิดปัญหาความล่าช้าในการเชื่อมต่อและความเป็นส่วนตัว มีการเสนอแผนการอื่น ๆ แต่ยังไม่ได้รับการนำไปใช้งานอย่างประสบความสำเร็จเพื่อเปิดใช้งานการตรวจสอบแบบตายตัว^{[ 31 ]}

• สภาความปลอดภัยของหน่วยงานออกใบรับรอง (CASC) – ในเดือนกุมภาพันธ์ พ.ศ. 2556 CASC ก่อตั้งขึ้นในฐานะองค์กรสนับสนุนอุตสาหกรรมที่อุทิศตนเพื่อแก้ไขปัญหาในอุตสาหกรรมและให้ความรู้แก่สาธารณชนเกี่ยวกับความปลอดภัยทางอินเทอร์เน็ต สมาชิกผู้ก่อตั้งคือหน่วยงานออกใบรับรองที่ใหญ่ที่สุดเจ็ดแห่ง^{[ 36 ] [ 37 ]}
• ฟอรัมมาตรฐานความปลอดภัยการประมวลผลทั่วไป (CCSF) – ในปี 2552 CCSF ก่อตั้งขึ้นเพื่อส่งเสริมมาตรฐานอุตสาหกรรมที่ปกป้องผู้ใช้ปลายทางMelih Abdulhayoğluซีอีโอของ Comodo Groupถือเป็นผู้ก่อตั้ง CCSF ^{[ 38 ]}
• CA/Browser Forum – ในปี 2548 ได้มีการจัดตั้งกลุ่มพันธมิตรใหม่ของหน่วยงานออกใบรับรองและผู้จำหน่ายเว็บเบราว์เซอร์ขึ้นเพื่อส่งเสริมมาตรฐานอุตสาหกรรมและข้อกำหนดพื้นฐานด้านความปลอดภัยทางอินเทอร์เน็ตMelih Abdulhayoğluซีอีโอของ Comodo Groupได้จัดการประชุมครั้งแรกและถือเป็นผู้ก่อตั้ง CA/Browser Forum ^{[ 39 ] [ 40 ]}

ฟอรัม CA/Browser เผยแพร่ข้อกำหนดพื้นฐาน^{[ 41 ]}ซึ่งเป็นรายการนโยบายและข้อกำหนดทางเทคนิคที่ CA ต้องปฏิบัติตาม ข้อกำหนดเหล่านี้เป็นสิ่งจำเป็นสำหรับการรวมอยู่ในที่เก็บใบรับรองของ Firefox ^{[ 42 ]}และ Safari ^{[ 43 ]}

เมื่อวันที่ 14 เมษายน 2568 ฟอรัม CA/Browser ได้ลงมติลดระยะเวลาสูงสุดของใบรับรอง SSL/TLS เหลือ 47 วันภายในวันที่ 15 มีนาคม 2562 ^{[ 44 ]}

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

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

กรณีการบิดเบือน CA ที่น่าสนใจเช่นนี้เกิดขึ้นในปี 2544 เมื่อVeriSign ซึ่งเป็นหน่วยงานออกใบรับรอง ได้ออกใบรับรองสองใบให้กับบุคคลที่อ้างว่าเป็นตัวแทนของ Microsoft ใบรับรองดังกล่าวมีชื่อว่า "Microsoft Corporation" ดังนั้นจึงสามารถใช้หลอกลวงผู้อื่นให้เชื่อว่าการอัปเดตซอฟต์แวร์ของ Microsoft มาจาก Microsoft ทั้งที่ความจริงแล้วไม่ใช่ การฉ้อโกงดังกล่าวถูกตรวจพบในช่วงต้นปี 2544 Microsoft และ VeriSign ได้ดำเนินการเพื่อจำกัดผลกระทบของปัญหา^{[ 45 ] [ 46 ]}

ในปี พ.ศ. 2551 Certstar ซึ่งเป็นตัวแทนจำหน่ายของ Comodo ได้ขายใบรับรองสำหรับ mozilla.com ให้กับ Eddy Nigg ซึ่งไม่มีอำนาจในการเป็นตัวแทนของ Mozilla ^{[ 47 ]}

ในปี 2554 มีการได้รับใบรับรองปลอมจาก Comodo และDigiNotar [ ^{48 ] [ 49 ] ซึ่งอ้างว่าเป็น ฝีมือ}ของแฮกเกอร์ชาวอิหร่าน มีหลักฐานว่าใบรับรอง DigiNotar ปลอมถูกนำไปใช้ในการโจมตีแบบ man-in-the-middleในอิหร่าน^{[ 50 ]}

ในปี 2555 เป็นที่ทราบกันว่า Trustwave ได้ออกใบรับรองรากย่อยที่ใช้สำหรับการจัดการทราฟฟิกแบบโปร่งใส (man-in-the-middle) ซึ่งอนุญาตให้องค์กรสามารถดักฟังทราฟฟิกเครือข่ายภายใน SSL โดยใช้ใบรับรองย่อยได้^{[ 51 ]}

ในปี 2555 มัลแวร์ Flame (หรือที่รู้จักกันในชื่อ SkyWiper) มีโมดูลที่เกิดการชนกันของ MD5 กับใบรับรองที่ถูกต้องซึ่งออกโดยใบรับรองการอนุญาตใช้งาน Microsoft Terminal Server ที่ใช้อัลกอริทึมแฮช MD5 ที่เสียหาย ผู้เขียนจึงสามารถทำการโจมตีแบบชนกันโดยใช้แฮชที่ระบุไว้ในใบรับรองได้^{[ 52 ] [ 53 ]}

ในปี 2558 หน่วยงานออกใบรับรองของจีนชื่อ MCS Holdings ซึ่งเป็นบริษัทในเครือของหน่วยงานจดทะเบียนโดเมนกลางของจีนได้ออกใบรับรองที่ไม่ได้รับอนุญาตสำหรับโดเมนของ Google ^{[ 54 ] [ 55 ]}ดังนั้น Google จึงได้ลบทั้ง MCS และหน่วยงานออกใบรับรองหลักออกจากChromeและเพิกถอนใบรับรอง^{[ 56 ]}

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

บางครั้ง CA จะใช้พิธีการสร้างกุญแจเมื่อสร้างกุญแจลงนาม เพื่อให้แน่ใจว่ากุญแจจะไม่ถูกแก้ไขหรือคัดลอก

จุดอ่อนที่สำคัญในวิธีการใช้งานระบบ X.509 ในปัจจุบันคือ CA ใดๆ ที่ได้รับความไว้วางใจจากฝ่ายใดฝ่ายหนึ่งสามารถออกใบรับรองสำหรับโดเมนใดๆ ก็ได้ตามที่ต้องการ ใบรับรองดังกล่าวจะได้รับการยอมรับว่าเป็นใบรับรองที่ถูกต้องโดยฝ่ายที่ให้ความไว้วางใจ ไม่ว่าจะเป็นใบรับรองที่ถูกต้องตามกฎหมายและได้รับอนุญาตหรือไม่ก็ตาม^{[ 57 ]} นี่เป็นข้อบกพร่องที่ร้ายแรง เนื่องจากเทคโนโลยีที่ใช้ X.509 และบุคคลที่สามที่ได้รับความไว้วางใจที่พบได้บ่อยที่สุดคือโปรโตคอล HTTPS เนื่องจากเว็บเบราว์เซอร์หลักๆ ทั้งหมดถูกแจกจ่ายให้กับผู้ใช้ปลายทางโดยมีการกำหนดค่าล่วงหน้าด้วยรายการ CA ที่เชื่อถือได้ซึ่งมีจำนวนหลายสิบรายการ นั่นหมายความว่า CA ที่ได้รับอนุมัติล่วงหน้าเหล่านี้สามารถออกใบรับรองที่ถูกต้องสำหรับโดเมนใดๆ ก็ได้^{[ 58 ]} การตอบสนองของอุตสาหกรรมต่อเรื่องนี้ค่อนข้างเงียบ^{[ 59 ]}เนื่องจากเนื้อหาของรายการ CA ที่เชื่อถือได้ที่กำหนดค่าไว้ล่วงหน้าของเบราว์เซอร์นั้นถูกกำหนดโดยอิสระโดยฝ่ายที่แจกจ่ายหรือทำให้มีการติดตั้งแอปพลิเคชันเบราว์เซอร์ จึงไม่มีอะไรที่ CA เองสามารถทำได้

ประเด็นนี้เป็นแรงผลักดันสำคัญในการพัฒนา โปรโตคอล การตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE) หากนำมาใช้ร่วมกับส่วนขยายความปลอดภัยของระบบชื่อโดเมน (DNSSEC) DANE จะช่วยลดบทบาทของบุคคลที่สามที่น่าเชื่อถือใน PKI ของโดเมนได้อย่างมาก หรืออาจกำจัดไปเลยก็ได้

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

• ชุง แทจุง; ล็อก เจย์; จันดราเซการัน บาลากฤษณัน; ชอฟฟ์เนส เดวิด; เลวิน เดฟ; แม็กส์ บรูซ เอ็ม.; มิสเลิฟ อลัน; รูลา จอห์น; ซัลลิแวน นิค; วิลสัน คริสโต (2018). "เว็บพร้อมสำหรับ OCSP Must-Staple แล้วหรือยัง?" (PDF) . รายงานการประชุม Internet Measurement Conference 2018.หน้า  105–118 . doi : 10.1145/3278532.3278543 . ISBN 9781450356190. S2CID  53223350 .
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: ระบบที่ปรับขนาดได้สำหรับการส่งการเพิกถอน TLS ทั้งหมดไปยังเบราว์เซอร์ทั้งหมด" การประชุมวิชาการ IEEE ว่าด้วยความปลอดภัยและความเป็นส่วนตัว (SP) ปี 2017หน้า  539–556 . doi : 10.1109/sp.2017.17 . ISBN 978-1-5090-5533-3. S2CID  3926509 .
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (พฤศจิกายน 2022). ข้อแนะนำสำหรับการใช้ งานTransport Layer Security (TLS) และ Datagram Transport Layer Security (DTLS) อย่างปลอดภัย IETF . doi : 10.17487/RFC9325 . RFC 9325 .
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: Scalable Global Certificate Revocation". Proceedings 2020 Network and Distributed System Security Symposium . doi : 10.14722/ndss.2020.24084 . ISBN 978-1-891562-61-7. S2CID  211268930 .

• ปัจจุบัน HTTPS มีความปลอดภัยมากแค่ไหน? ถูกโจมตีบ่อยแค่ไหน? ( มูลนิธิ Electronic Frontier Foundation , 25 ตุลาคม 2554)