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

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

เนื่องจากค่าใช้จ่ายในการตรวจสอบการเพิกถอนใบรับรองและผลกระทบต่อความพร้อมใช้งานจากบริการระยะไกลที่ไม่น่าเชื่อถือเว็บเบราว์เซอร์จึงจำกัดการตรวจสอบการเพิกถอนที่ดำเนินการ และจะล้มเหลวแบบอ่อน (fail-soft) หาก พบว่ามีการตรวจสอบดังกล่าว รายการเพิกถอนใบรับรองนั้นใช้แบนด์วิดท์สูงเกินไปสำหรับการใช้งานเป็นประจำ และโปรโตคอลสถานะใบรับรองออนไลน์ (Online Certificate Status Protocol)ก่อให้เกิดปัญหาเรื่องความหน่วงในการเชื่อมต่อและความเป็นส่วนตัว มีการเสนอแนวทางอื่น ๆ แต่ยังไม่ได้รับการนำไปใช้งานอย่างประสบความสำเร็จเพื่อเปิดใช้งานการตรวจสอบแบบสมบูรณ์ (fail-hard)

เอซีเอ็ม

สภาพแวดล้อมการจัดการใบรับรองอัตโนมัติ

ซีเอ

หน่วยงานออกใบรับรอง

ซีเอ/บี

ฟอรัม CA/เบราว์เซอร์

ซีอาร์แอล

รายชื่อการเพิกถอนใบรับรอง

ซีอาร์วี

เวกเตอร์การเพิกถอนใบรับรอง

โอซีเอสพี

โปรโตคอลสถานะใบรับรองออนไลน์

พีไอไอ

โครงสร้างพื้นฐานกุญแจสาธารณะ

ทีแอลเอส

การรักษาความปลอดภัยระดับการขนส่ง

ช่อง โหว่ Heartbleedซึ่งถูกเปิดเผยในปี 2014 ทำให้เกิดการเพิกถอนใบรับรองจำนวนมาก เนื่องจากคีย์ส่วนตัวอาจรั่วไหลGlobalSignเพิกถอนใบรับรองที่ออกไปกว่า 50% StartComถูกวิพากษ์วิจารณ์ที่ออกใบรับรองฟรี แต่กลับเรียกเก็บค่าธรรมเนียมในการเพิกถอน^{[ 1 ]}

การศึกษาในปี 2015 พบว่าอัตราการเพิกถอนโดยรวมอยู่ที่ 8% สำหรับใบรับรองที่ใช้บนเว็บ^{[ 2 ]}แม้ว่าอัตรานี้อาจสูงขึ้นเนื่องจาก Heartbleed ก็ตาม^{[ 3 ]}

แม้ว่าความปลอดภัยของเว็บจะเป็นสิ่งสำคัญสำหรับเบราว์เซอร์ ส่วนใหญ่ แต่เนื่องจากความหน่วงและความต้องการแบนด์วิดท์ที่เกี่ยวข้องกับ OCSP และ CRL เบราว์เซอร์จึงจำกัดการตรวจสอบสถานะใบรับรอง^{[ 4 ]}ในปี 2015 Google Chromeตรวจสอบเฉพาะ ใบรับรอง Extended Validation เท่านั้น เบราว์เซอร์บนมือถือไม่ได้ทำการตรวจสอบความถูกต้อง และไม่มีเบราว์เซอร์ใดตรวจสอบใบรับรองทั้งหมดอย่างสมบูรณ์^{[ 5 ]} Chrome และ Firefox ทำการตรวจสอบแบบพุชสำหรับโดเมนจำนวนเล็กน้อยที่ถือว่ามีความสำคัญ^{[ 6 ]} Chrome เรียกสิ่งเหล่านี้ว่าCRLsetsและในปี 2025 ครอบคลุมการเพิกถอนประมาณ 1% โดยมีค่าใช้จ่ายในการดาวน์โหลดรายวัน 600 kB ^{[ 7 ]}เบราว์เซอร์มีความเห็นไม่ตรงกันในกรณีพิเศษเกี่ยวกับความถูกต้องของใบรับรอง ซึ่งอาจทำให้ผู้ใช้ที่มีประสบการณ์สับสนได้^{[ 8 ]}

จำนวนใบรับรองในWeb PKIเพิ่มขึ้นอย่างมหาศาลในช่วงปลายทศวรรษ 2010 จาก 30 ล้านใบในเดือนมกราคม 2017 เป็น 434 ล้านใบในเดือนมกราคม 2020 ปัจจัยสำคัญในการเติบโตนี้คือLet's Encrypt ที่ให้ ใบรับรองที่ตรวจสอบโดเมนได้ฟรีขนาดของชุดใบรับรองที่อาจถูกเพิกถอนได้นั้นกำหนดข้อกำหนดเกี่ยวกับความสามารถในการปรับขนาดของกลไกการเพิกถอน^{[ 4 ]}

Chuat et al. (2020)เรียกการเพิกถอนว่า "เป็นเรื่องที่ท้าทายอย่างมาก" ^{[ 9 ]}ในปี 2022 RFC 9325 ระบุว่าการเพิกถอนใบรับรองเป็นปัญหาสำคัญที่มี "วิธีแก้ปัญหาที่สมบูรณ์และมีประสิทธิภาพ" แนะนำให้ใช้ OCSP และ OCSP stapling เป็น "พื้นฐานสำหรับวิธีแก้ปัญหาที่เป็นไปได้" ^{[ 10 ]}

Firefox ได้นำ CRLite มาใช้กับผู้ใช้เดสก์ท็อปทั้งหมดในปี 2025 นี่เป็นการนำการตรวจสอบการเพิกถอนที่ครอบคลุมเพื่อปกป้องความเป็นส่วนตัวมาใช้ในเว็บเบราว์เซอร์เป็นครั้งแรก^{[ 7 ]}

การเพิกถอนใบรับรองถือเป็น "เครื่องมือสำคัญ" ในการจัดการกับการโจมตีและการรั่วไหลโดยไม่ได้ตั้งใจ RFC 9325 กำหนดข้อกำหนดเชิงบรรทัดฐานสำหรับการใช้งาน TLS ให้มีวิธีการบางอย่างในการไม่เชื่อถือใบรับรอง^{[ 10 ]}หากไม่มีการเพิกถอน ผู้โจมตีสามารถใช้ใบรับรองที่ถูกบุกรุกเพื่อปลอมตัวเป็นเจ้าของจนกว่าจะหมดอายุ^{[ 4 ]}

การเพิกถอนอาจไม่จำเป็นสำหรับใบรับรองที่มีอายุสั้นพอสมควร โดยประมาณอยู่ในช่วงไม่กี่ชั่วโมงถึงไม่กี่วัน ซึ่งเทียบได้กับอายุการตอบสนองของ OCSP การออกใบรับรองบ่อยครั้งที่เกี่ยวข้องมักต้องใช้ระบบอัตโนมัติ (เช่น โปรโตคอล ACME) และอาจสร้างภาระให้กับองค์ประกอบโครงสร้างพื้นฐานอื่นๆ (เช่น บันทึกความโปร่งใส) ^{[ 11 ]}ใบรับรองที่มีอายุสั้นยังก่อให้เกิดความซับซ้อนในการกลับมาเชื่อมต่อ TLS อีกครั้ง แม้ว่าจะไม่จำเป็นต้องแก้ไขไม่ได้ก็ตาม^{[ 12 ]}

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

สถานะการเพิกถอนมักจะไม่ได้รับการเก็บรักษาและจัดเก็บไว้นานเกินกว่าวันหมดอายุของใบรับรอง ทำให้การวิจัยและการตรวจสอบพฤติกรรมการเพิกถอนทำได้ยาก^{[ 16 ]}ข้อเสนอหนึ่งในการแก้ปัญหานี้คือการส่ง 'ใบรับรองหลังการเพิกถอน' ไปยังบันทึก Certificate Transparency สำหรับการเพิกถอนแต่ละครั้ง ซึ่งจะช่วยให้สามารถดำเนินการเพิกถอนได้โดยไม่ต้องมีการดำเนินการใดๆ จาก CA ^{[ 17 ]}ข้อเสนอทางเลือกอีกข้อหนึ่งซึ่งอิงตาม Certificate Transparency เช่นกัน คือการส่ง CRV ไปยังบันทึก CT โดย CA ^{[ 18 ]}

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

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

การล้มเหลวอย่างรุนแรงอาจนำไปสู่ช่องทางการโจมตีแบบปฏิเสธการให้บริการแบบใหม่ ตัวอย่างเช่น หากไคลเอ็นต์คาดหวัง OCSP stapling และล้มเหลวอย่างรุนแรงในกรณีอื่น การปฏิเสธการให้บริการต่อผู้ตอบสนอง OCSP จะถูกขยายไปสู่การปฏิเสธการให้บริการต่อบริการทั้งหมดที่ต้องการใช้การตอบสนอง OCSP เหล่านั้น^{[ 11 ]}

มีสองสถานการณ์สำหรับการประเมินการใช้ทรัพยากร ได้แก่ สภาวะปกติ และเหตุการณ์การเพิกถอนจำนวนมาก แผนการเพิกถอนควรมีประสิทธิภาพภายใต้สภาวะปกติ และใช้งานได้ในระหว่างเหตุการณ์การเพิกถอนจำนวนมาก^{[ 4 ]}

การเรียกข้อมูลการเพิกถอนทำให้เกิดค่าใช้จ่ายด้านแบนด์วิดท์และเวลาแฝงสำหรับลูกค้า^{[ 21 ]}

ในระหว่าง เหตุการณ์ Heartbleedครั้งใหญ่ในปี 2014 ซึ่งอัตราการเพิกถอนเพิ่มขึ้นจาก 1% เป็น 11% Cloudflareประเมินว่าแบนด์วิดท์ที่GlobalSignใช้ในการแจกจ่าย CRL อาจมีค่าใช้จ่าย 400,000 ดอลลาร์สหรัฐ (เทียบเท่ากับ 540,000 ดอลลาร์สหรัฐในปี 2025 ^{[ 22 ]} ) ^{[ 23 ]}

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

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

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

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

มีสถาปัตยกรรมหลักสามแบบสำหรับวิธีที่ไคลเอ็นต์เข้าถึงสถานะการเพิกถอน ได้แก่แบบดึง (pull-based)ซึ่งไคลเอ็นต์จะดึงสถานะการเพิกถอนในเวลาตรวจสอบความถูกต้องแบบผลัก (push-based)ซึ่งไคลเอ็นต์จะดึงสถานะการเพิกถอนก่อนการตรวจสอบความถูกต้องและแคชไว้ และแบบ ช่วยเหลือโดย เครือข่าย (network-assisted ) ซึ่งการตรวจสอบการเพิกถอนจะถูกรวมเข้ากับโปรโตคอล TLS อย่างแน่นหนา และอาจไม่จำเป็นต้องมีการตรวจสอบแยกต่างหาก^{[ 28 ]}

การตรวจสอบแบบดึงข้อมูลมักมีปัญหาเรื่องความล่าช้าและความพร้อมใช้งาน ลูกค้าที่ทำการตรวจสอบแบบดึงข้อมูลมักจะแคชการตอบกลับไว้ในช่วงเวลาสั้นๆ การตรวจสอบแบบดึงข้อมูลอย่างเดียวร่วมกับ failing-soft ไม่ได้เพิ่มความปลอดภัย^{[ 29 ]}

การตรวจสอบแบบพุชมีประสิทธิภาพแบนด์วิดท์น้อยกว่าการตรวจสอบแบบพูล แต่ได้ความพร้อมใช้งานและความเป็นส่วนตัวเพิ่มขึ้น สามารถใช้วิธีการที่แตกต่างกันได้ในแต่ละใบรับรอง ทำให้สามารถปรับแต่งการแลกเปลี่ยนได้อย่างละเอียด: ทั้งGoogle ChromeและMozilla Firefoxทำการตรวจสอบแบบพุชกับชุดใบรับรองที่สำคัญจำนวนเล็กน้อย^{[ 29 ]}

รายการเพิกถอนใบรับรอง (CRL) จะแสดงรายการใบรับรองที่ถูกเพิกถอน ใบรับรองเหล่านี้ได้รับการตรวจสอบความถูกต้องทางการเข้ารหัสโดย CA ที่ออกใบรับรอง^{[ 30 ]}

CRL มีปัญหาเรื่องความสามารถในการปรับขนาด และขึ้นอยู่กับว่าไคลเอ็นต์สามารถเข้าถึงเครือข่ายได้เพียงพอเพื่อดาวน์โหลดก่อนที่จะตรวจสอบสถานะของใบรับรอง^{[ 10 ]}

CRL ประกอบด้วยข้อมูลเกี่ยวกับใบรับรองทั้งหมดที่ถูกเพิกถอนโดย CA ซึ่งหมายความว่าผู้จัดจำหน่ายและลูกค้าต้องเสียค่าใช้จ่ายในการถ่ายโอนข้อมูลที่อาจไม่เกี่ยวข้อง^{[ 31 ]}การศึกษาในปี 2015 พบว่าใบรับรองโดยเฉลี่ยมี CRL ขนาด 51 kB และ CRL ที่ใหญ่ที่สุดมีขนาด 76 MB ^{[ 2 ]}

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

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

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

การศึกษาในปี 2018 พบว่า 1.7% ของคำขอไปยังผู้ตอบสนองไม่สามารถใช้งานได้ในระดับเครือข่าย และอีกประมาณ 2% ทำให้เกิดการตอบสนอง OCSP ที่ใช้ไม่ได้ โดยมีความแตกต่างกันอย่างมากระหว่าง CA และมุมมองของไคลเอ็นต์^{[ 33 ]}

OCSP stapling เป็นส่วนขยายของ TLS ที่ให้การตอบสนอง OCSP แก่ไคลเอ็นต์พร้อมกับใบรับรองเมื่อเริ่มต้นการเชื่อมต่อ^{[ 31 ]}

OCSP stapling สามารถแก้ปัญหาความท้าทายในการปฏิบัติงานของ OCSP ได้ กล่าวคือ การร้องขอเครือข่ายเพิ่มเติมที่ทำให้เกิดความล่าช้าและการลดทอนความเป็นส่วนตัว^{[ 34 ]}อย่างไรก็ตาม อาจมีความเสี่ยงต่อการโจมตีแบบลดระดับโดยผู้โจมตีแบบ on-path ^{[ 10 ]} RFC 7633 กำหนดส่วนขยายที่ฝังข้อกำหนดลงในใบรับรองที่จะต้องแนบไปกับคำตอบ OCSP ที่ถูกต้อง^{[ 35 ]}ด้วยส่วนขยายนี้ การแนบใบรับรองจะมีประสิทธิภาพในกรณีที่ใบรับรองถูกบุกรุกหลังจากออกอย่างถูกต้องแล้ว อย่างไรก็ตาม หากใบรับรองสามารถออกผิดพลาดได้หากไม่มีส่วนขยาย การแนบใบรับรองอาจไม่ให้ความปลอดภัยใดๆ^{[ 36 ]}

นอกเหนือจากไคลเอนต์และ CA ที่เปิดใช้งานการผูกมัดและส่วนขยาย must-staple แล้ว ผู้ดูแลระบบเซิร์ฟเวอร์ยังต้องดำเนินการเพื่อสนับสนุนการผูกมัดโดยการดึงการตอบสนองเป็นประจำและส่งให้กับไคลเอนต์ในระหว่างการจับมือ ในปี 2018 มีเพียง Firefox เท่านั้นที่รองรับ must-staple และเว็บเซิร์ฟเวอร์ที่ใช้มากที่สุดสองตัว ( Apache httpdและNginx ) ก็ไม่รองรับการผูกมัด OCSP เลย^{[ 37 ]}

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

CRLite is deployable, only requiring an aggregator to retrieve CRLs from CAs and then provide the filter cascade and updates to it, and for clients to use it; no action from CAs is needed, and nor is any needed from certificate holders.^[24] The aggregator does not need to be a trusted third party: the filter cascade can be audited to prove that it accurately reflects the input CRLs.^[39]Private CAs also require special handling within CRLite;^[40] data from Firefox suggests that 5% of certificates are not in CT logs, either due to private CAs or merge delay.^[41]

In the initial design, CRLite was a cascade of Bloom filters.^[38] A single filter constructed from a list of revoked certificates produces false positives. With an open domain, this is an insuperable problem for revocation checking. However, by using Certificate Transparency to enumerate all unexpired certificates, an exhaustive list of false positives can be produced. This list is then used to construct a second filter, which is consulted if a certificate matches the first (and hence has a strictly smaller domain); if the second filter does not match, then it is a true positive and the certificate has been revoked; however, a match in the second filter may be a false negative, necessitating a third filter, and so on. As the universe is finite and the domain of each filter strictly decreases at each step, this procedure produces a finite filter cascade.^[42]

The revocation status of all certificates in the Web PKI in January was estimated to be 10 MB in size when using the Bloom filter cascade, with updates of 580 kB per day. In March 2018, this had grown to 18 MB.^[29] In a simulation with 100 million certificates, a 1% daily expiration rate, and a 2% revocation rate, CRLite required an initial provision of 3.1 MB, and then 408 kB per day for updates.^[43] Mozilla, in a trial deployment of CRLite, found in 2024 that the amortised download rate was 26 MB over 10 days.^[38]

ต่อมา CRLite ได้รับการปรับปรุงให้ใช้อัลกอริทึมใหม่ที่มีประสิทธิภาพมากขึ้น เรียกว่าclubcardsซึ่งช่วยลดการใช้ข้อมูล รวมถึงการสังเกตว่าการเพิกถอนไม่ได้กระจายอย่างสม่ำเสมอทั่ว CA (เช่น CA บางแห่งมีอัตราการเพิกถอนสูงกว่า CA อื่นๆ อย่างต่อเนื่อง) หรือตลอดช่วงเวลา (เช่น เนื่องจากเหตุการณ์การเพิกถอนจำนวนมาก) และการแบ่งส่วนใบรับรองตามพารามิเตอร์เหล่านี้จะช่วยเพิ่มประสิทธิภาพได้^{[ 44 ]}การดาวน์โหลดข้อมูลทดสอบการเป็นสมาชิก clubcard ครั้งแรกในปี 2024 มีขนาด 7.0 MB ครอบคลุมใบรับรองที่ถูกต้อง 903 ล้านใบและใบรับรองที่ถูกเพิกถอน 8.7 ล้านใบ การอัปเดตซึ่งสร้างขึ้นทุกหกชั่วโมงมีขนาดเฉลี่ย 95.5 kB แต่สามารถบีบอัดเหลือ 26.0 kB ได้ ด้วยการแบ่งส่วนเฉพาะผู้ออกใบรับรองเท่านั้น จะอยู่ภายใน 12% ของขอบเขตล่างตามทฤษฎี ด้วยการแบ่งส่วนที่ซับซ้อนมากขึ้นโดยใช้ทั้งวันหมดอายุ/วันออกใบรับรองด้วย ปริมาณที่เหลือที่จะใช้ประโยชน์ได้จะสูงถึง 116% ^{[ 45 ]}

หลังจากการทดลองใช้งานเบื้องหลังฟีเจอร์แฟล็กของการออกแบบ CRLite ครั้งแรกใน Firefox เวอร์ชัน 68 ^{[ 38 ]} Mozilla ได้นำการออกแบบที่แก้ไขแล้วมาใช้ใน Firefox เวอร์ชัน 137 และในเดือนสิงหาคม 2025 ได้ปิดใช้งาน OCSP สำหรับใบรับรองที่ตรวจสอบโดเมนใน Firefox 142 ^{[ 7 ]}ทำให้การเปลี่ยนไปใช้ CRLite ในการใช้งานจริงมีประสิทธิภาพ^{[ 46 ]}ในการทดสอบในห้องปฏิบัติการ พบว่าการตรวจสอบการเพิกถอนใช้เวลาเพียง 10 ไมโครวินาทีต่อใบรับรอง และจากข้อมูลภาคสนาม เวลาเฉลี่ยในการจับมือ TLS ลดลงจาก 172.4 มิลลิวินาทีเหลือ 143.4 มิลลิวินาที ซึ่งเป็นผลมาจากการไม่จำเป็นต้องดึงการตอบสนอง OCSP ^{[ 45 ]}

Let's Revoke ใช้เวกเตอร์บิตของสถานะการเพิกถอน (เรียกว่าเวกเตอร์การเพิกถอนใบรับรองหรือ CRV) เพื่อให้ไคลเอนต์สามารถเรียกสถานะการเพิกถอนจำนวนมากได้อย่างมีประสิทธิภาพ^{[ 4 ]} CA สร้าง CRV สำหรับใบรับรองของตนเอง โดยมี CRV หนึ่งรายการต่อวันหมดอายุ การบำรุงรักษา CRV สำหรับ CA เป็นไปตามจำนวนใบรับรองที่ออก CA ต้องเพิ่มฟิลด์ใหม่ หมายเลขการเพิกถอน ลงในใบรับรองที่ออกแต่ละใบ ทำให้สามารถระบุใบรับรองจาก CA เดียวกันได้ด้วยคู่ของวันหมดอายุของใบรับรองและหมายเลขการเพิกถอน คู่นี้ช่วยให้ไคลเอนต์สามารถค้นหาบิตที่ให้สถานะของใบรับรองที่ระบุภายใน CRV ได้อย่างมีประสิทธิภาพ CRV อาจถูกบีบอัด คาดว่าจะบีบอัดได้ดีมาก เนื่องจากบิตส่วนใหญ่จะไม่ได้ตั้งค่าไว้เกือบตลอดเวลา เนื่องจาก CRV แต่ละรายการเชื่อมโยงกับวันหมดอายุที่กำหนดไว้ CRV เก่าจึงสามารถถูกทิ้งได้อย่างมีประสิทธิภาพ การอัปเดต CRV จะถูกจัดเป็นชุด โดยมีการประทับเวลาและลงนามในการอัปเดตเพื่อแจกจ่ายให้กับไคลเอนต์^{[ 47 ]}การอัปเดตอาจอยู่ในรูปแบบใดรูปแบบหนึ่งจากสามรูปแบบ โดยตัวเลือกที่เหมาะสมที่สุดจะขึ้นอยู่กับอัตราการเพิกถอน ซึ่งช่วยให้สามารถดำเนินการตามปกติได้อย่างมีประสิทธิภาพและจัดการเหตุการณ์เพิกถอนจำนวนมากได้^{[ 48 ]}

คาดว่า CRV จะมีขนาดเล็กพอที่จะเปิดใช้งานการตรวจสอบแบบพุช แต่ไคลเอ็นต์ที่มีข้อจำกัดมากกว่าอาจยังคงทำการตรวจสอบแบบพูล โดยเข้าถึง CRV ที่เลือกไว้เท่านั้น หรือเลื่อนการดึงข้อมูล CRV ออกไปจนกว่าจะมีการตรวจสอบความถูกต้องของใบรับรอง^{[ 49 ]}ไคลเอ็นต์ที่ใช้ Let's Revoke กับการตรวจสอบแบบพุชสามารถล้มเหลวอย่างรุนแรงสำหรับใบรับรองใดๆ ที่มีหมายเลขการเพิกถอน^{[ 24 ]}ผลกระทบต่อความเป็นส่วนตัวและความพร้อมใช้งานของ Let's Revoke ขึ้นอยู่กับสถาปัตยกรรม: หากการตรวจสอบทั้งหมดเป็นแบบพุช จะไม่มีการรั่วไหลของความเป็นส่วนตัวและลดความเสี่ยงต่อการโจมตีแบบปฏิเสธการให้บริการหรือการหยุดทำงาน อย่างไรก็ตาม หากใช้การตรวจสอบแบบพูล ข้อมูลบางอย่างเกี่ยวกับกิจกรรมของผู้ใช้จะรั่วไหล (ในรูปแบบของ CRV ที่เข้าถึง) และ CRV อาจไม่สามารถเข้าถึงได้ในเวลาตรวจสอบความถูกต้อง^{[ 24 ]}

ในการจำลองด้วยใบรับรอง 100 ล้านใบ อัตราการหมดอายุรายวัน 1% และอัตราการเพิกถอน 2% Let's Revoke ต้องการพื้นที่เริ่มต้น 2.2 MB จากนั้น 114 kB ต่อวันสำหรับการอัปเดต^{[ 50 ]}

Let's Revoke ยังไม่ได้รับการใช้งานอย่างแพร่หลาย^{[ 10 ]}นอกเหนือจากการใช้งานฝั่งไคลเอ็นต์แล้ว ยังต้องการให้ CA ทำการเปลี่ยนแปลงการดำเนินงาน^{[ 51 ]}และไม่ได้ให้ข้อมูลมากเท่ากับ CRL หรือ OCSP (เพียงบิตต่อใบรับรองสำหรับความถูกต้อง) CRL หรือ OCSP อาจยังคงใช้เพื่อเสริม Let's Revoke และให้ข้อมูลเพิ่มเติมนั้น^{[ 52 ]}การใช้งานสามารถทำได้ทีละ CA โดยไคลเอ็นต์จะได้รับประโยชน์จากพฤติกรรม fail-hard ทีละน้อย เนื่องจากประสิทธิภาพของ CRV เหนือกว่า CRL และการตอบสนองของ OCSP ทำให้ CA อาจได้รับแรงจูงใจในการใช้งาน Let's Revoke ^{[ 51 ]}

เทคนิค การเรียกค้นข้อมูลส่วนตัวสามารถบรรเทาความกังวลเรื่องความเป็นส่วนตัวได้ด้วยการตรวจสอบแบบดึงข้อมูล^{[ 53 ]}แทนที่จะให้ไคลเอนต์ทำการตรวจสอบการเพิกถอนเอง มิดเดิลบ็อกซ์อาจทำแทน โดยรวมศูนย์ต้นทุนการตรวจสอบการเพิกถอนและกระจายต้นทุนนั้นไปทั่วการเชื่อมต่อจำนวนมาก ไคลเอนต์ไม่จำเป็นต้องจัดสรรพื้นที่จัดเก็บข้อมูลสำหรับการเพิกถอน^{[ 54 ]}ข้อเสนออีกประการหนึ่งเกี่ยวข้องกับการออกอากาศข้อมูลการเพิกถอนทางวิทยุFM ^{[ 42 ]}

• "ข้อกำหนดพื้นฐานสำหรับการออกและการจัดการใบรับรองที่ได้รับการยอมรับจากสาธารณะ" (PDF) CA /Browser Forum 14 ธันวาคม 2022
• Bruhner, Carl Magnus; Linnarsson, Oscar; Nemec, Matus; Arlitt, Martin; Carlsson, Niklas (2022). "การเปลี่ยนเวรยาม: การจัดการใบรับรองและกุญแจสาธารณะบนอินเทอร์เน็ต"การวัดแบบพาสซีฟและ แอ คทีฟ บันทึกการบรรยายในวิทยาการคอมพิวเตอร์ เล่มที่ 13210 หน้า  50–80 doi : 10.1007 /978-3-030-98785-5_3 ISBN 978-3-030-98784-8.
• Chuat, Laurent; Abdou, Abdelrahman; Sasse, Ralf; Sprenger, Christoph; Basin, David; Perrig, Adrian (2020). "SoK: การมอบหมายและการเพิกถอน จุดเชื่อมโยงที่ขาดหายไปในห่วงโซ่ความเชื่อมั่นของเว็บ" การประชุมวิชาการด้านความปลอดภัยและความเป็นส่วนตัวแห่งยุโรปของ IEEE ประจำปี 2020 (EuroS&P)หน้า  624–638 . arXiv : 1906.10775 . doi : 10.1109/EuroSP48549.2020.00046 . ISBN 978-1-7281-5087-1S2CID 215827701​ ​
• ชุง แทจุง; ล็อก เจย์; จันดราเซการัน บาลากฤษณัน; ชอฟฟ์เนส เดวิด; เลวิน เดฟ; แม็กส์ บรูซ เอ็ม.; มิสเลิฟ อลัน; รูลา จอห์น; ซัลลิแวน นิค; วิลสัน คริสโต (2018). "เว็บพร้อมสำหรับ OCSP Must-Staple แล้วหรือยัง?" (PDF) . รายงานการประชุม Internet Measurement Conference 2018.หน้า  105–118 . doi : 10.1145/3278532.3278543 . ISBN 9781450356190. S2CID  53223350 .
• Durumeric, Zakir; Li, Frank; Kasten, James; Amann, Johanna; Beekman, Jethro; Payer, Mathias; Weaver, Nicolas; Adrian, David; Paxson, Vern; Bailey, Michael; Halderman, J. Alex (2014). "The Matter of Heartbleed". รายงานการประชุมวิชาการด้านการวัดผลทางอินเทอร์เน็ต ปี 2014หน้า  475–488 . doi : 10.1145/2663716.2663755 . ISBN 9781450332132S2CID 142767​ ​
• Hallam-Baker, Phillip (ตุลาคม 2015). ส่วนขยายคุณสมบัติความปลอดภัยของเลเยอร์การขนส่ง (TLS) X.509v3 . IETF . doi : 10.17487 /RFC7633 . RFC 7633 .
• Kogan, Dmitry; Corrigan-Gibbs, Henry (สิงหาคม 2021). "การค้นหาบล็อกลิสต์ส่วนตัวด้วยเช็คลิสต์" . การประชุมวิชาการด้านความปลอดภัย USENIX ครั้งที่ 30 (USENIX Security 21) . สมาคม USENIX . หน้า  875–892 . ISBN 978-1-939133-24-3.
• Korzhitskii, Nikita; Carlsson, Niklas (2021). " สถานะการเพิกถอนบนอินเทอร์เน็ต" การวัด แบบพาสซีฟและแอคทีฟ บันทึกการบรรยายในวิทยาการคอมพิวเตอร์ เล่มที่ 12671 หน้า  175–191 arXiv : 2102.04288 doi : 10.1007/978-3-030-72582-2_11 ISBN 978-3-030-72581-5. S2CID  231846906 .
• คอร์ชิตสกี้, นิกิตา; เนเม็ค, มาตุส; คาร์ลสัน, นิคลาส (2022) "เอกสารรับรองเพื่อความโปร่งใสในการเพิกถอน" arXiv : 2203.02280 .{{cite journal}}: การอ้างอิงวารสารต้องใช้|journal=( ความช่วยเหลือ )
• 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 .
• Leibowitz, Hemi; Ghalwash, Haitham; Syta, Ewa; Herzberg, Amir (2021). "CTng: ใบรับรองที่ปลอดภัยและความโปร่งใสในการเพิกถอน"คลังเอกสารอิเล็กทรอนิกส์ด้านการเข้ารหัสลับ
• Liu, Yabing; Tome, Will; Zhang, Liang; Choffnes, David; Levin, Dave; Maggs, Bruce; Mislove, Alan; Schulman, Aaron; Wilson, Christo (2015). "การวัดการเพิกถอนใบรับรองแบบครบวงจรใน PKI ของเว็บ". รายงานการประชุม Internet Measurement Conference ปี 2015.หน้า  183–196 . doi : 10.1145/2815675.2815685 . ISBN 9781450338486. S2CID  1955346 .
• Prince, Matthew (17 เมษายน 2557). "ต้นทุนที่ซ่อนเร้นของ Heartbleed" . บล็อก Cloudflare . Cloudflare .
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (พฤศจิกายน 2022). ข้อแนะนำสำหรับการใช้ งานTransport Layer Security (TLS) และ Datagram Transport Layer Security (DTLS) อย่างปลอดภัย IETF . doi : 10.17487/RFC9325 . RFC 9325 .
• Schanck, John (2025). Clubcards สำหรับ WebPKI: การทดสอบการเพิกถอนใบรับรองขนาดเล็กในทางทฤษฎีและการปฏิบัติ 2025 IEEE Symposium on Security and Privacy (SP). doi : 10.1109/SP61157.2025.00128 .
• Schanck, John (19 สิงหาคม 2025b). "CRLite: การตรวจสอบการเพิกถอนใบรับรองที่รวดเร็ว เป็นส่วนตัว และครอบคลุมใน Firefox – Mozilla Hacks - บล็อกสำหรับนักพัฒนาเว็บ" . Mozilla Hacks – บล็อกสำหรับนักพัฒนาเว็บ. สืบค้นเมื่อ19 สิงหาคม 2025 .
• 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 .
• Szalachowski, Pawel; Chuat, Laurent; Lee, Taeho; Perrig, Adrian (2016). "RITM: การเพิกถอนในระหว่างกระบวนการ". การประชุมวิชาการนานาชาติ IEEE ครั้งที่ 36 ว่าด้วยระบบคอมพิวเตอร์แบบกระจาย (ICDCS) ปี 2016.หน้า  189–200 . arXiv : 1604.08490 . doi : 10.1109/ICDCS.2016.91 . ISBN 978-1-5090-1483-5S2CID 761560​ ​
• Wazan, AS; Laborde, R.; Chadwick, DW; Barrere, F.; Benzekri, A. (11 กันยายน 2017). "การตรวจสอบความถูกต้องของการเชื่อมต่อ TLS โดยเว็บเบราว์เซอร์: ทำไมเว็บเบราว์เซอร์ยังคงไม่เห็นด้วย?" . การประชุมวิชาการด้านซอฟต์แวร์คอมพิวเตอร์และการประยุกต์ใช้งานประจำปีครั้งที่ 41 ของ IEEE (COMPSAC) . หน้า  665–674 . doi : 10.1109/COMPSAC.2017.240 . ISBN 9781538603673S2CID 28599113​ ​