ในด้านการเข้ารหัสลับ X.509 เป็นมาตรฐานของสหภาพโทรคมนาคมระหว่างประเทศ (ITU ) ที่กำหนดรูปแบบของใบรับรองกุญแจสาธารณะ^{[ 1 ]}ใบรับรอง X.509 ถูกใช้ในโปรโตคอลอินเทอร์เน็ตหลายตัว รวมถึงTLS/SSLซึ่งเป็นพื้นฐานของHTTPS [ ^{2 ]}โปรโตคอลที่ปลอดภัยสำหรับการท่องเว็บ^{นอกจาก}นี้ยังใช้ในแอปพลิเคชันแบบออฟไลน์ เช่นลายเซ็นอิเล็กทรอนิกส์^{[ 1 ]}

ใบรับรอง X.509 เชื่อมโยงข้อมูลประจำตัวกับกุญแจสาธารณะโดยใช้ลายเซ็นดิจิทัล ใบรับรองประกอบด้วยข้อมูลประจำตัว ( ชื่อโฮสต์องค์กร หรือบุคคล) และกุญแจสาธารณะ ( RSA , DSA , ECDSA , ed25519เป็นต้น) และอาจลงนามโดยหน่วยงานออกใบรับรอง (CA) หรือลงนามด้วยตนเอง เมื่อใบรับรองลงนามโดยหน่วยงานออกใบรับรองที่เชื่อถือได้ หรือได้รับการตรวจสอบโดยวิธีการอื่น ผู้ที่ถือใบรับรองนั้นสามารถใช้กุญแจสาธารณะที่อยู่ในใบรับรองเพื่อสร้างการสื่อสารที่ปลอดภัยกับอีกฝ่าย หรือตรวจสอบเอกสารที่ลงนามแบบดิจิทัลด้วยกุญแจส่วนตัว ที่เกี่ยวข้อง ได้

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

มาตรฐาน X.509 ถูกกำหนดโดย "ภาคส่วนการกำหนดมาตรฐาน" ของ ITU ( ITU-T 's SG17 ) ในกลุ่มศึกษา ITU-T ที่ 17 และอิงตามAbstract Syntax Notation One (ASN.1) ซึ่งเป็นมาตรฐาน ITU-T อีกมาตรฐานหนึ่ง

มาตรฐาน X.509 ได้รับการเผยแพร่ครั้งแรกเมื่อวันที่ 3 กรกฎาคม 1988 โดยเริ่มต้นจากการพัฒนาร่วมกับ มาตรฐาน X.500ภารกิจแรกเริ่มของมาตรฐานนี้คือการให้ผู้ใช้เข้าถึงทรัพยากรข้อมูลได้อย่างปลอดภัยและป้องกันการโจมตีแบบ man-in-the-middle ทางด้านการเข้ารหัส มาตรฐานนี้ ใช้ระบบลำดับชั้นที่เข้มงวดของหน่วยงานออกใบรับรอง (CA) ซึ่งแตกต่างจาก โมเดล เครือข่ายความไว้วางใจเช่นPGPที่ใครก็ได้ (ไม่ใช่เฉพาะ CA พิเศษ) สามารถลงนามและรับรองความถูกต้องของใบรับรองกุญแจของผู้อื่นได้

X.509 เวอร์ชัน 3 มีความยืดหยุ่นในการรองรับโทโพโลยีอื่นๆ เช่นบริดจ์และเมช [ ^{2 ] สามารถ}ใช้ในเว็บความไว้วางใจแบบ peer-to-peer เหมือน OpenPGPได้ แต่แทบจะไม่เคยใช้ในลักษณะนั้นเลยในปี 2547 ระบบ X.500 ได้รับการนำไปใช้โดยประเทศอธิปไตยเพื่อวัตถุประสงค์ในการปฏิบัติตามสนธิสัญญาการแบ่งปันข้อมูลเอกลักษณ์ของรัฐเท่านั้น และ กลุ่มงานโครงสร้างพื้นฐานกุญแจสาธารณะ (X.509) (PKIX) ของ IETFได้ปรับมาตรฐานให้เข้ากับการจัดระเบียบอินเทอร์เน็ตที่มีความยืดหยุ่นมากขึ้น อันที่จริง คำว่าใบรับรอง X.509มักหมายถึงใบรับรอง PKIX ของ IETF และ โปรไฟล์ CRLของมาตรฐานใบรับรอง X.509 v3 ตามที่ระบุไว้ในRFC  5280ซึ่งโดยทั่วไปเรียกว่า PKIX สำหรับโครงสร้างพื้นฐานกุญแจสาธารณะ (X.509 ) ^{[ 3 ]}

ปัญหาแรกๆ ของโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) และใบรับรอง X.509 คือปัญหา "ไดเร็กทอรีใด" ที่รู้จักกันดี ปัญหาคือไคลเอนต์ไม่รู้ว่าจะดึงใบรับรองระดับกลางที่หายไปได้จากที่ใด เนื่องจากไดเร็กทอรี X.500 ทั่วโลกไม่เคยเกิดขึ้นจริง ปัญหานี้ได้รับการแก้ไขโดยการรวมใบรับรองระดับกลางทั้งหมดไว้ในคำขอ ตัวอย่างเช่น เว็บเซิร์ฟเวอร์ในยุคแรกๆ จะส่งเฉพาะใบรับรองของเว็บเซิร์ฟเวอร์ไปยังไคลเอนต์เท่านั้น ไคลเอนต์ที่ไม่มีใบรับรอง CA ระดับกลางหรือไม่ทราบว่าจะหาได้จากที่ใด จะไม่สามารถสร้างเส้นทางที่ถูกต้องจาก CA ไปยังใบรับรองของเซิร์ฟเวอร์ได้ เพื่อแก้ไขปัญหานี้ ปัจจุบันเว็บเซิร์ฟเวอร์จึงส่งใบรับรองระดับกลางทั้งหมดพร้อมกับใบรับรองของเว็บเซิร์ฟเวอร์^{[ 4 ]}

แม้ว่า PKIX จะหมายถึงมาตรฐาน PKI ของ IETF หรืออินเทอร์เน็ต แต่ก็มี PKI อื่นๆ อีกมากมายที่มีนโยบายแตกต่างกัน ตัวอย่างเช่น รัฐบาลสหรัฐฯ มี PKI ของตนเองพร้อมนโยบายของตนเอง และ CA/Browser Forum ก็มี PKI ของตนเองพร้อมนโยบายของตนเองเช่นกัน PKI ของรัฐบาลสหรัฐฯ เป็นเอกสารขนาดใหญ่ที่มีมากกว่า 2,500 หน้า หาก PKI ขององค์กรแตกต่างจากของ IETF หรือ CA/Browser Forum มากเกินไป องค์กรนั้นก็อาจเสี่ยงต่อการสูญเสียความสามารถในการทำงานร่วมกันกับเครื่องมือทั่วไป เช่นเว็บเบราว์เซอร์ cURL และ Wget ตัวอย่างเช่น หาก PKI มีนโยบายในการออกใบรับรองเฉพาะวันจันทร์เท่านั้น เครื่องมือทั่วไปอย่าง cURL และ Wget จะไม่บังคับใช้นโยบายดังกล่าวและจะอนุญาตให้ใช้ใบรับรองที่ออกในวันอังคารได้^{[ 4 ]}

ใบรับรอง X.509 เชื่อมโยงตัวตนกับกุญแจสาธารณะโดยใช้ลายเซ็นดิจิทัล ในระบบ X.509 มีใบรับรองสองประเภท ประเภทแรกคือใบรับรอง CA และประเภทที่สองคือใบรับรองผู้ใช้ปลายทาง ใบรับรอง CA สามารถออกใบรับรองอื่นๆ ได้ ใบรับรอง CA ระดับสูงสุดที่ลงนามด้วยตนเองบางครั้งเรียกว่าใบรับรอง Root CA ใบรับรอง CA อื่นๆ เรียกว่าใบรับรอง Intermediate CA หรือใบรับรอง Subordinate CA ใบรับรองผู้ใช้ปลายทางระบุตัวตนผู้ใช้ เช่น บุคคล องค์กร หรือธุรกิจ ใบรับรองผู้ใช้ปลายทางไม่สามารถออกใบรับรองอื่นๆ ได้ ใบรับรองผู้ใช้ปลายทางบางครั้งเรียกว่าใบรับรอง Leaf เนื่องจากไม่สามารถออกใบรับรองอื่นๆ ที่อยู่ต่ำกว่าได้

องค์กรที่ต้องการใบรับรองที่ลงนามแล้วจะขอจากหน่วยงานออกใบรับรอง (CA) โดยใช้โปรโตคอล เช่นCertificate Signing Request (CSR) , Simple Certificate Enrollment Protocol (SCEP)หรือCertificate Management Protocol (CMP)องค์กรจะสร้างคู่คีย์ ขึ้นมาก่อน โดยเก็บคีย์ส่วนตัวไว้เป็นความลับและใช้คีย์นั้นในการลงนาม CSR CSR จะมีข้อมูลระบุตัวตนของผู้ขอและคีย์สาธารณะ ของผู้ขอ ซึ่งใช้ในการตรวจสอบลายเซ็นของ CSR รวมถึงDistinguished Name (DN) ซึ่งเป็นชื่อเฉพาะสำหรับบุคคล องค์กร หรือธุรกิจนั้นๆ CSR อาจแนบมาพร้อมกับเอกสารรับรองหรือหลักฐานยืนยันตัวตนอื่นๆ ที่หน่วยงานออกใบรับรองต้องการ

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

ใบรับรองรากที่เชื่อถือได้ขององค์กรสามารถแจกจ่ายให้กับพนักงานทุกคนเพื่อให้พวกเขาสามารถใช้ระบบ PKI ของบริษัทได้ เบราว์เซอร์เช่นInternet Explorer , Firefox , Opera , SafariและChromeมาพร้อมกับชุดใบรับรองรากที่กำหนดไว้ล่วงหน้าซึ่งติดตั้งไว้แล้ว ดังนั้น ใบรับรอง SSLจากหน่วยงานออกใบรับรองหลักๆ จะทำงานได้ทันที ในทางปฏิบัติ นักพัฒนาเบราว์เซอร์จะเป็นผู้กำหนดว่า CA ใดเป็นบุคคลที่สามที่เชื่อถือได้สำหรับผู้ใช้เบราว์เซอร์ ตัวอย่างเช่น Firefox มีไฟล์ CSV และ/หรือ HTML ที่มีรายการ CA ที่รวมอยู่^{[ 7 ]}

X.509 และ RFC 5280ยังรวมถึงมาตรฐานสำหรับ การใช้งาน รายการเพิกถอน ใบรับรอง (CRL) ด้วย วิธีการตรวจสอบความถูกต้องของใบรับรองอีกวิธี หนึ่งที่ IETF อนุมัติคือ Online Certificate Status Protocol (OCSP) Firefox 3.0เปิดใช้งานการตรวจสอบ OCSP เป็นค่าเริ่มต้น เช่นเดียวกับWindows เวอร์ชัน ตั้งแต่Vistaขึ้นไป^{[ 8 ]} 

โครงสร้างที่กำหนดไว้ในมาตรฐานนั้นแสดงออกมาในรูปแบบภาษาที่เป็นทางการ คือAbstract Syntax Notation One (ASN.1)

โครงสร้างของใบรับรองดิจิทัล X.509 v3 มีดังนี้:

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

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

โครงสร้างของเวอร์ชัน 1 ระบุไว้ใน RFC 1422 

รูปแบบภายในของตัวระบุเฉพาะของผู้ออกและหัวเรื่องที่ระบุไว้ในX.520 The Directory:ข้อแนะนำ ประเภทแอตทริบิวต์ที่เลือก

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

มีการเพิ่มส่วนขยายเข้ามาในเวอร์ชัน 3 หน่วยงานออกใบรับรอง (CA) สามารถใช้ส่วนขยายเพื่อออกใบรับรองสำหรับวัตถุประสงค์เฉพาะเท่านั้น (เช่น ใช้สำหรับการลงนามในวัตถุดิจิทัล เท่านั้น )

ในทุกเวอร์ชัน หมายเลขประจำเครื่องจะต้องไม่ซ้ำกันสำหรับใบรับรองแต่ละใบที่ออกโดย CA เฉพาะราย (ตามที่ระบุไว้ในRFC 5280 )  

RFC  5280 (และเวอร์ชันก่อนหน้า) กำหนดส่วนขยายใบรับรองจำนวนหนึ่ง ซึ่งระบุวิธีการใช้งานใบรับรอง ส่วนใหญ่เป็นส่วนต่อขยายจากjoint-iso-ccitt(2) ds(5) id-ce(29)OID ส่วนขยายที่พบบ่อยที่สุดบางส่วน ซึ่งกำหนดไว้ในหัวข้อ 4.2.1 มีดังนี้:

• ข้อจำกัดพื้นฐาน{ id-ce 19 }[ ^{9 ] : §4.2.1.9 ใช้เพื่อระบุว่าใบรับรองนั้นเป็นใบรับรอง CA และสามารถรับรองหรือออกใบรับรองอื่น ได้}หรือไม่ ข้อจำกัดสามารถทำเครื่องหมายว่าเป็นข้อจำกัดที่สำคัญได้ หากข้อจำกัดถูกทำเครื่องหมายว่าเป็นข้อจำกัดที่สำคัญ ตัวแทนจะต้องไม่ดำเนินการประมวลผลใบรับรองหากตัวแทนไม่เข้าใจข้อจำกัดนั้น ตัวแทนสามารถดำเนินการประมวลผลข้อจำกัดที่ไม่สำคัญต่อไปได้แม้ว่าจะไม่เข้าใจก็ตาม
• การใช้งานคีย์{ id-ce 15 }[ ^{9 ] : §4.2.1.3 จัดเตรียมบิตแมปที่ระบุการดำเนินการเข้ารหัสลับที่อาจดำเนินการโดยใช้คีย์สาธารณะที่มีอยู่ในใบรับรอง ตัวอย่างเช่น อาจระบุว่าควรใช้คีย์สำหรับการลงนาม แต่ไม่ใช่สำหรับ การ}เข้ารหัส
• การใช้งานคีย์แบบขยาย{ id-ce 37 }[ ^{9 ] : §4.2.1.12 มักใช้กับใบรับรองใบ เพื่อ ระบุ}วัตถุประสงค์ของคีย์สาธารณะที่อยู่ในใบรับรอง ประกอบด้วยรายการ OID ซึ่งแต่ละ OID ระบุการใช้งานที่อนุญาต ตัวอย่างเช่นระบุว่าคีย์อาจใช้ในฝั่งเซิร์ฟเวอร์ของการเชื่อมต่อ TLS หรือ SSL; ระบุว่าคีย์อาจใช้เพื่อรักษาความปลอดภัยอีเมล{ id-pkix 3 1 }{ id-pkix 3 4 }

โดยทั่วไปเมื่อใช้RFC 5280หากใบรับรองมีส่วนขยายหลายรายการที่จำกัดการใช้งาน ข้อจำกัดทั้งหมดจะต้องได้รับการปฏิบัติตามเพื่อให้การใช้งานที่กำหนดมีความเหมาะสม RFC ให้ตัวอย่างเฉพาะของใบรับรองที่มีทั้ง keyUsage และ extendedKeyUsage: ในกรณีนี้ ทั้งสองจะต้องได้รับการประมวลผล และใบรับรองจะสามารถใช้งานได้ก็ต่อเมื่อส่วนขยายทั้งสองมีความสอดคล้องกันในการระบุการใช้งานของใบรับรอง ตัวอย่างเช่นNSSใช้ส่วนขยายทั้งสองเพื่อระบุการใช้งานใบรับรอง^{[ 10 ]} 

หน่วยงานออกใบรับรองที่ดำเนินการภายใต้ PKI ของ CA/Browser Forum ออกใบรับรองที่มีระดับการตรวจสอบความถูกต้องที่แตกต่างกัน การตรวจสอบความถูกต้องที่แตกต่างกันจะให้ระดับความมั่นใจที่แตกต่างกันว่าใบรับรองนั้นแสดงถึงสิ่งที่ควรจะเป็น ตัวอย่างเช่น เว็บเซิร์ฟเวอร์สามารถตรวจสอบความถูกต้องได้ในระดับความมั่นใจต่ำสุดโดยใช้การตรวจสอบความถูกต้องของโดเมน(Domain Validation หรือ DV)หรือเว็บเซิร์ฟเวอร์สามารถตรวจสอบความถูกต้องได้ในระดับความมั่นใจที่สูงขึ้นโดยใช้วิธีการที่ละเอียดกว่าที่เรียกว่าการตรวจสอบความถูกต้องแบบขยาย (Extended Validation หรือ EV )

ในทางปฏิบัติ ใบรับรอง DV หมายถึงใบรับรองที่ออกให้สำหรับโดเมนexample.comหลังจากที่ได้มีการยืนยันการควบคุมโดเมนนั้นแล้ว เช่น โดยการตอบอีเมลที่ส่งไปยัง[email protected]ใบรับรอง EV หมายถึงใบรับรองที่ออกให้สำหรับโดเมนexample.comและบริษัท เช่น Example, LLC เป็นเจ้าของโดเมน และเจ้าของได้รับการยืนยันโดยเอกสารการจัดตั้งบริษัท

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

การตรวจสอบความถูกต้องแบบขยาย (Extended Validation) จะถูกระบุในใบรับรองโดยใช้ส่วนขยาย X.509 v3 แต่ละ CA จะใช้Object Identifier (OID) ที่แตกต่างกัน เพื่อยืนยันการตรวจสอบความถูกต้องแบบขยาย ไม่มี OID เดียวที่ใช้ระบุการตรวจสอบความถูกต้องแบบขยาย ซึ่งทำให้ การเขียนโปรแกรม User Agent ซับซ้อนขึ้น User Agent แต่ละตัวจะต้องมีรายการ OID ที่ระบุการตรวจสอบความถูกต้องแบบขยาย

PKI ของ CA/Browser Forum ยอมรับการตรวจสอบความถูกต้องแบบขยาย (Extended Validation หรือ EV) PKI อื่นๆ เช่น PKI ของอินเทอร์เน็ต (PKIX) ไม่ได้ให้ความสำคัญเป็นพิเศษกับการตรวจสอบความถูกต้องแบบขยาย เครื่องมือที่ใช้นโยบาย PKIX เช่น cURL และ Wget จะถือว่าใบรับรอง EV เหมือนกับใบรับรองอื่นๆ จนถึงปี 2019 เบราว์เซอร์หลายตัวเคยแสดงผลตอบรับทางสายตาที่ชัดเจนในแถบ URL เพื่อระบุว่าเว็บไซต์นั้นมีใบรับรอง EV หลังจากการศึกษาและรายงานที่แสดงให้เห็นถึงความไม่ประสิทธิภาพของใบรับรอง EV และประโยชน์ของมันสำหรับอาชญากรในการแทรกองค์ประกอบที่ทำให้เข้าใจผิดลงในส่วนกลางของ UI ของเบราว์เซอร์ เบราว์เซอร์หลักทั้งหมดจึงลบผลตอบรับทางสายตาที่โดดเด่นก่อนหน้านี้ออกจากแถบ URL ^{[ 11 ] [ 12 ] [ 13 ]} แทนที่จะเป็นเช่นนั้น ตั้งแต่ปี 2019 เบราว์เซอร์เช่นChromiumและFirefoxจะซ่อนข้อมูล EV ที่ออกให้ไว้ในเมนูย่อย ซึ่งจะแสดงในลักษณะที่เป็นกลาง โดยไม่มีการเน้นหรือกล่าวถึงการตรวจสอบความถูกต้องแบบขยายแต่อย่างใด

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

มีนามสกุลไฟล์ ที่ใช้กันทั่วไปหลายแบบ สำหรับใบรับรอง X.509 นามสกุลไฟล์บางส่วนเหล่านี้ยังใช้สำหรับข้อมูลอื่นๆ เช่น คีย์ส่วนตัวด้วย

• .pem– ( อีเมลที่มีความเป็นส่วนตัวสูง ) ใบรับรองDERที่เข้ารหัสBase64 ซึ่งอยู่ระหว่าง และ-----BEGIN CERTIFICATE----------END CERTIFICATE-----
• .cerโดย ปกติ .crtแล้ว ใบรับรอง .derจะอยู่ในรูปแบบไบนารีDERแต่ใบรับรองที่เข้ารหัสแบบ Base64 ก็พบได้ทั่วไปเช่นกัน (ดู.pemด้านบน)
• .p8– คีย์ส่วนตัวที่ส่งออกตามที่ระบุไว้ในPKCS#8อาจอยู่ในรูปแบบ DER หรือ PEM ที่ขึ้นต้นด้วยคีย์ที่เข้ารหัสจะขึ้นต้นด้วย.p8eและอาจมีส่วนขยาย.pk8-----BEGIN PRIVATE KEY----------BEGIN ENCRYPTED PRIVATE KEY-----.p8e
• .p10– PKCS#10คำขอลงนามใบรับรอง (CSR) ในรูปแบบ PEM เริ่มต้นด้วย. สิ่งเหล่านี้ถูกสร้างขึ้นเพื่อส่งไปยังหน่วยงานออกใบรับรอง (CA) ประกอบด้วยรายละเอียดสำคัญของใบรับรองที่ร้องขอ เช่น ชื่อทั่วไป (/CN) หัวข้อ องค์กร รัฐ ประเทศ รวมถึง.csrคีย์สาธารณะของใบรับรองที่จะลงนาม สิ่งเหล่านี้จะได้รับการลงนามโดย CA และใบรับรองจะถูกส่งกลับ ใบรับรองที่ส่งกลับคือใบรับรอง สาธารณะ (ซึ่งรวมถึงคีย์สาธารณะแต่ไม่ใช่คีย์ส่วนตัว) ซึ่งสามารถอยู่ในรูปแบบต่างๆ ได้ แต่โดยปกติจะเป็น. ^{[ 14 ]}-----BEGIN CERTIFICATE REQUEST-----.p7r
• .p7r– การตอบกลับ PKCS#7ต่อ CSR ประกอบด้วยใบรับรองที่ลงนามใหม่และใบรับรองของ CA เอง
• .p7s– ลายเซ็นดิจิทัล PKCS#7อาจมีไฟล์หรือข้อความต้นฉบับที่ลงนามแล้ว ใช้ในS/MIMEสำหรับการลงนามอีเมล กำหนดไว้ใน RFC 2311
• .p7m– PKCS#7 (SignedData, EnvelopedData) ข้อความที่เข้ารหัส ("enveloped"), ข้อความ หรือจดหมายอีเมล MIME นิยามไว้ใน RFC 2311
• .p7c– PKCS#7ได้ลดทอนโครงสร้าง SignedData เหลือเพียง "certs-only" โดยไม่มีข้อมูลใดๆ ให้ลงนาม ตามที่กำหนดไว้ใน RFC 2311
• .p7b– PKCS#7โครงสร้างข้อมูลที่ลงนามแล้วโดยไม่มีข้อมูล มีเพียงชุดใบรับรองและ/หรือCRL (พบได้น้อย) แต่ไม่มีคีย์ส่วนตัว ใช้ รูปแบบ DERหรือBERหรือ PEM ที่ขึ้นต้นด้วย . รูปแบบที่ Windows ใช้สำหรับ .keystoreการแลกเปลี่ยนใบรับรอง รองรับโดย Java แต่ส่วนใหญ่จะใช้เป็นส่วนขยายแทน ต่างจากใบรับรองแบบสไตล์ รูปแบบนี้มี วิธีการ ที่กำหนดไว้ในการรวมใบรับรองเส้นทางการรับรอง-----BEGIN PKCS7-----.keystore.pem
• .p12– PKCS#12อาจประกอบด้วยใบรับรอง (สาธารณะ) และคีย์ส่วนตัว (ป้องกันด้วยรหัสผ่าน) ในไฟล์เดียว– Personal Information eXchange PFX ซึ่งเป็นรุ่นก่อนหน้าของ PKCS#12 (โดยปกติจะมี .pfxข้อมูลในรูปแบบ PKCS#12 เช่น ไฟล์ PFX ที่สร้างในIIS ).pkcs12.pfx
• .crl– รายการเพิกถอนใบรับรอง (Certificate Revocation List หรือ CRL) หน่วยงานออกใบรับรองจะจัดทำรายการเหล่านี้เพื่อเพิกถอนใบรับรองก่อนหมดอายุ

PKCS#7เป็นมาตรฐานสำหรับการลงนามหรือเข้ารหัส (เรียกอย่างเป็นทางการว่า "การห่อหุ้ม") ข้อมูล เนื่องจากจำเป็นต้องใช้ใบรับรองเพื่อตรวจสอบข้อมูลที่ลงนามแล้ว จึงสามารถรวมใบรับรองไว้ในโครงสร้าง SignedData ได้

ห่วง โซ่ใบรับรอง (เรียกอีกอย่างว่า "เส้นทางการรับรอง" ^{[ 9 ] : §3.2} ) คือรายการใบรับรอง (โดยปกติจะเริ่มต้นด้วยใบรับรองของเอนทิตีปลายทาง) ตามด้วย ใบรับรอง CA หนึ่งใบหรือมากกว่า (โดยปกติใบสุดท้ายจะเป็นใบรับรองที่ลงนามด้วยตนเอง) ซึ่งมีคุณสมบัติดังต่อไปนี้:

1. ผู้ออกใบรับรองแต่ละใบ (ยกเว้นใบสุดท้าย) ตรงกับผู้ออกใบรับรองใบถัดไปในรายการ
2. ใบรับรองแต่ละใบ (ยกเว้นใบสุดท้าย) จะถูกลงนามด้วยกุญแจลับที่สอดคล้องกับใบรับรองถัดไปในห่วงโซ่ (กล่าวคือ สามารถตรวจสอบลายเซ็นของใบรับรองหนึ่งได้โดยใช้กุญแจสาธารณะที่อยู่ในใบรับรองถัดไป)
3. ใบรับรองสุดท้ายในรายการคือใบรับรองที่เชื่อถือได้ (Trust Anchor ): ใบรับรองที่คุณเชื่อถือได้เพราะได้รับมาจากกระบวนการที่น่าเชื่อถือ

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

คำอธิบายในย่อหน้าก่อนหน้านี้เป็นมุมมองที่เรียบง่ายเกี่ยวกับกระบวนการตรวจสอบความถูกต้องของเส้นทางการรับรอง [ ^{9 ] : §6 ซึ่งเกี่ยวข้องกับการตรวจสอบ เพิ่มเติม}เช่น การตรวจสอบความถูกต้องของใบรับรอง การค้นหาCRLเป็นต้น

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

ในแผนภาพเหล่านี้:

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

เพื่อให้สามารถจัดการให้ใบรับรองผู้ใช้ที่มีอยู่ใน PKI 2 (เช่น "ผู้ใช้ 2") ได้รับความไว้วางใจจาก PKI 1 นั้น CA1 จะสร้างใบรับรอง (cert2.1) ที่มีคีย์สาธารณะของ CA2 ^{[ 16 ]} ตอนนี้ทั้ง "cert2" และ "cert2.1" (สีเขียว) มีหัวเรื่องและคีย์สาธารณะเดียวกัน ดังนั้นจึงมีเชนที่ถูกต้องสองเชนสำหรับ cert2.2 (ผู้ใช้ 2): "cert2.2 → cert2" และ "cert2.2 → cert2.1 → cert1"

ในทำนองเดียวกัน CA2 สามารถสร้างใบรับรอง (cert1.1) ที่มีกุญแจสาธารณะของ CA1 เพื่อให้ใบรับรองผู้ใช้ที่มีอยู่ใน PKI 1 (เช่น "ผู้ใช้ 1") ได้รับความไว้วางใจจาก PKI 2

ทำความเข้าใจเกี่ยวกับการสร้างเส้นทางการรับรอง (PDF) . PKI Forum. กันยายน 2002. เก็บถาวรจากต้นฉบับ(PDF)เมื่อ 2019-02-04 . เรียกดูเมื่อ2014-11-07 .เพื่อให้การเปลี่ยนผ่านจากคู่คีย์ลงนามเก่าไปยังคู่คีย์ลงนามใหม่เป็นไปอย่างราบรื่น CA ควรออกใบรับรองที่มีคีย์สาธารณะเก่าที่ลงนามโดยคีย์ลงนามส่วนตัวใหม่ และใบรับรองที่มีคีย์สาธารณะใหม่ที่ลงนามโดยคีย์ลงนามส่วนตัวเก่า ใบรับรองทั้งสองฉบับนี้ออกโดย CA เอง แต่ไม่ได้ลงนามโดย CA เองโปรดทราบว่าใบรับรองเหล่านี้เป็นส่วนเพิ่มเติมจากใบรับรองที่ลงนามโดย CA สองฉบับ (หนึ่งฉบับเก่า หนึ่งฉบับใหม่)

เนื่องจากทั้ง cert1 และ cert3 มีคีย์สาธารณะเดียวกัน (คีย์เก่า) จึงมีห่วงโซ่ใบรับรองที่ถูกต้องสองห่วงโซ่สำหรับ cert5 ได้แก่ "cert5 → cert1" และ "cert5 → cert3 → cert2" และในทำนองเดียวกันสำหรับ cert6 ซึ่งทำให้สามารถเชื่อถือใบรับรองผู้ใช้เก่า (เช่น cert5) และใบรับรองใหม่ (เช่น cert6) ได้อย่างไม่แตกต่างกันโดยฝ่ายที่มีใบรับรอง CA รูทใหม่หรือใบรับรอง CA รูทเก่าเป็นจุดยึดความเชื่อถือในระหว่างการเปลี่ยนไปใช้คีย์ CA ใหม่^{[ 17 ]}

นี่คือตัวอย่างของใบรับรอง X.509 ที่ถอดรหัสแล้ว ซึ่งเคยใช้โดย wikipedia.org และเว็บไซต์วิกิพีเดียอื่นๆ อีกหลายแห่ง ใบรับรองนี้ออกโดยGlobalSignดังที่ระบุไว้ในช่อง Issuer ช่อง Subject ระบุว่า Wikipedia เป็นองค์กร และช่อง Subject Alternative Name (SAN) สำหรับ DNS ระบุชื่อโฮสต์ที่สามารถใช้ใบรับรองนี้ได้ ช่อง Subject Public Key Info มี คีย์สาธารณะ ECDSAในขณะที่ลายเซ็นด้านล่างสร้างขึ้นโดย คีย์ส่วนตัว RSA ของ GlobalSign (ลายเซ็นในตัวอย่างเหล่านี้ถูกตัดทอน)

ใบรับรอง: ข้อมูล: เวอร์ชัน: 3 (0x2) หมายเลขประจำเครื่อง: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 อัลกอริทึมลายเซ็น: sha256WithRSAEncryption ผู้ออกใบรับรอง: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 ความถูกต้อง ไม่ก่อนวันที่: 21 พฤศจิกายน 2016 เวลา 08:00:00 GMT ไม่ใช่หลังจากนั้น : 22 พฤศจิกายน 2017 07:59:59 GMT เรื่อง: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org ข้อมูลคีย์สาธารณะของหัวเรื่อง: อัลกอริทึมกุญแจสาธารณะ: id-ecPublicKey กุญแจสาธารณะ: (256 บิต) ผับ: 00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9d:3b:ef ASN1 OID: prime256v1 เส้นโค้ง NIST: P-256 ส่วนขยาย X509v3: การใช้งานคีย์ X509v3: สำคัญ ลายเซ็นดิจิทัล, ข้อตกลงกุญแจ การเข้าถึงข้อมูลของหน่วยงาน: ผู้ออกใบรับรอง CA - URI: http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2 นโยบายใบรับรอง X509v3: นโยบาย: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ นโยบาย: 2.23.140.1.2.2 ข้อจำกัดพื้นฐานของ X509v3: CA:เท็จ จุดกระจาย CRL ของ X509v3: ชื่อเต็ม: URI: http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 ชื่อทางเลือกของหัวเรื่อง: DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org วิธีใช้งานคีย์เสริม X509v3: การตรวจสอบสิทธิ์เว็บเซิร์ฟเวอร์ TLS, การตรวจสอบสิทธิ์เว็บไคลเอ็นต์ TLS รหัสระบุหัวข้อ X509v3: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 รหัสระบุคีย์อำนาจ X509v3: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C 

 อัลกอริทึมลายเซ็น: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35: ... 

ในการตรวจสอบความถูกต้องของใบรับรองปลายทางนี้ จำเป็นต้องมีใบรับรองระดับกลางที่ตรงกับผู้ออกใบรับรองและตัวระบุคีย์ผู้มีอำนาจ:

ในการเชื่อมต่อ TLS เซิร์ฟเวอร์ที่ตั้งค่าอย่างถูกต้องจะให้ใบรับรองระดับกลางเป็นส่วนหนึ่งของการจับมือ (handshake) อย่างไรก็ตาม ยังสามารถดึงใบรับรองระดับกลางได้โดยการดึง URL "CA Issuers" จากใบรับรองปลายทาง (end-entity certificate)

นี่คือตัวอย่างของใบรับรองระดับกลางที่เป็นของหน่วยงานออกใบรับรอง ใบรับรองนี้ได้ลงนามในใบรับรองปลายทางด้านบน และได้รับการลงนามโดยใบรับรองรากด้านล่าง โปรดสังเกตว่าฟิลด์หัวเรื่อง (subject field) ของใบรับรองระดับกลางนี้ตรงกับฟิลด์ผู้ออกใบรับรอง (issuer field) ของใบรับรองปลายทางที่ลงนาม นอกจากนี้ ฟิลด์ "ตัวระบุคีย์หัวเรื่อง" (subject key identifier) ​​ในใบรับรองระดับกลางยังตรงกับฟิลด์ "ตัวระบุคีย์หน่วยงานออกใบรับรอง" (authority key identifier) ​​ในใบรับรองปลายทางด้วย

ใบรับรอง: ข้อมูล: เวอร์ชัน: 3 (0x2) หมายเลขประจำเครื่อง: 04:00:00:00:00:01:44:4e:f0:42:47 อัลกอริทึมลายเซ็น: sha256WithRSAEncryption ผู้ออกบัตร: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA ความถูกต้อง ไม่ก่อนวันที่: 20 กุมภาพันธ์ 2014 เวลา 10:00:00 GMT ไม่หลังจากวันที่ 20 กุมภาพันธ์ 2024 เวลา 10:00:00 GMT เรื่อง: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 ข้อมูลคีย์สาธารณะของหัวเรื่อง: อัลกอริทึมกุญแจสาธารณะ: rsaEncryption คีย์สาธารณะ: (2048 บิต) ค่าสัมบูรณ์: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... เลขชี้กำลัง: 65537 (0x10001) ส่วนขยาย X509v3: การใช้งานคีย์ X509v3: สำคัญ ลายเซ็นใบรับรอง, ลายเซ็น CRL ข้อจำกัดพื้นฐานของ X509v3: วิกฤต CA:TRUE, pathlen:0 รหัสระบุหัวข้อ X509v3: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C นโยบายใบรับรอง X509v3: นโยบาย: X509v3 นโยบายใดๆ CPS: https://www.globalsign.com/repository/ จุดกระจาย CRL ของ X509v3: ชื่อเต็ม: URI: http://crl.globalsign.net/root.crl การเข้าถึงข้อมูลของหน่วยงาน: OCSP - URI: http://ocsp.globalsign.com/rootr1 รหัสระบุคีย์อำนาจ X509v3: รหัส:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:เอฟซี:FD:4B อัลกอริทึมลายเซ็น: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ... 

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

ใบรับรอง: [ 18 ] ข้อมูล: เวอร์ชัน: 3 (0x2) หมายเลขประจำเครื่อง: 04:00:00:00:00:01:15:4b:5a:c3:94 อัลกอริทึมลายเซ็น: sha1WithRSAEncryption ผู้ออกบัตร: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA ความถูกต้อง ห้ามก่อนวันที่ 1 กันยายน 1998 เวลา 12:00:00 GMT ไม่หลังจากวันที่ 28 มกราคม 2028 เวลา 12:00:00 GMT เรื่อง: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA ข้อมูลคีย์สาธารณะของหัวเรื่อง: อัลกอริทึมกุญแจสาธารณะ: rsaEncryption คีย์สาธารณะ: (2048 บิต) ค่าสัมบูรณ์: 00:ดา:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... เลขชี้กำลัง: 65537 (0x10001) ส่วนขยาย X509v3: การใช้งานคีย์ X509v3: สำคัญ ลายเซ็นใบรับรอง, ลายเซ็น CRL ข้อจำกัดพื้นฐานของ X509v3: วิกฤต CA:TRUE รหัสระบุหัวข้อ X509v3: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:เอฟซี:FD:4B อัลกอริทึมลายเซ็น: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ... 

มีเอกสารเผยแพร่จำนวนมากเกี่ยวกับปัญหา PKI โดยBruce Schneier , Peter Gutmannและผู้เชี่ยวชาญด้านความปลอดภัยอื่นๆ^{[ 19 ] [ 20 ] [ 21 ]}

• การใช้การบล็อกใบรับรองที่ไม่ถูกต้อง (โดยใช้CRLและOCSP )
  • หากไคลเอนต์เชื่อถือใบรับรองเฉพาะเมื่อมี CRL เท่านั้น พวกเขาจะสูญเสียความสามารถในการใช้งานแบบออฟไลน์ซึ่งทำให้ PKI น่าสนใจ ดังนั้นไคลเอนต์ส่วนใหญ่จึงเชื่อถือใบรับรองเมื่อไม่มี CRL แต่ในกรณีนั้น ผู้โจมตีที่ควบคุมช่องทางการสื่อสารสามารถปิดใช้งาน CRL ได้ Adam Langley จาก Google กล่าวว่าการตรวจสอบ CRL แบบ soft-fail เปรียบเสมือนเข็มขัดนิรภัยที่ใช้งานได้ยกเว้นเมื่อเกิดอุบัติเหตุ^{[ 22 ]}
• CRL ถือเป็นตัวเลือกที่ไม่เหมาะสมอย่างยิ่ง เนื่องจากมีขนาดใหญ่และมีรูปแบบการกระจายตัวที่ซับซ้อน
• ความหมายของ OCSP ที่ไม่ชัดเจน และการขาดสถานะการเพิกถอนในอดีต
• ประเด็นเรื่องการเพิกถอนใบรับรองรากไม่ได้ถูกกล่าวถึง
• ปัญหาการรวมกลุ่ม : การยืนยันตัวตน (การตรวจสอบสิทธิ์ด้วยตัวระบุ), การยืนยันคุณลักษณะ (การส่งชุดคุณลักษณะที่ผ่านการตรวจสอบแล้ว) และการยืนยันนโยบาย ถูกรวมไว้ในคอนเทนเนอร์เดียว ซึ่งก่อให้เกิดปัญหาด้านความเป็นส่วนตัว การกำหนดนโยบาย และการบำรุงรักษา
• ปัญหาการมอบหมายอำนาจ : CA ไม่สามารถจำกัด CA ย่อยไม่ให้ออกใบรับรองนอกเนมสเปซหรือชุดแอตทริบิวต์ที่จำกัดได้ คุณสมบัติของ X.509 นี้ไม่ได้ถูกนำมาใช้ ดังนั้นจึงมี CA จำนวนมากบนอินเทอร์เน็ต และการจำแนกประเภทและนโยบายของ CA เหล่านั้นเป็นงานที่ไม่สามารถทำได้ การมอบหมายอำนาจภายในองค์กรไม่สามารถจัดการได้เลย เหมือนกับการปฏิบัติทางธุรกิจทั่วไป^{[ 23 ]}
• ปัญหาของสหพันธ์ : ห่วงโซ่ใบรับรองที่เกิดจาก CA ระดับรอง CA ระดับกลาง และการลงนามข้าม ทำให้การตรวจสอบความถูกต้องซับซ้อนและมีค่าใช้จ่ายสูงในแง่ของเวลาในการประมวลผล ความหมายของการตรวจสอบเส้นทางอาจไม่ชัดเจน รูปแบบลำดับชั้นที่มีบุคคลที่สามที่เชื่อถือได้เป็นรูปแบบเดียวที่มีอยู่ ซึ่งไม่สะดวกเมื่อมีความสัมพันธ์ความไว้วางใจแบบทวิภาคีอยู่แล้ว
• การออกใบรับรอง Extended Validation (EV)สำหรับชื่อโฮสต์ไม่ได้ป้องกันการออกใบรับรองที่มีระดับการตรวจสอบต่ำกว่าซึ่งใช้ได้กับชื่อโฮสต์เดียวกัน ซึ่งหมายความว่าระดับการตรวจสอบที่สูงกว่าของ EV ไม่ได้ป้องกันการโจมตีแบบ man-in-the-middle ^{[ 24 ]}

• บุคคลหรือองค์กรที่ซื้อใบรับรองมักจะใช้หน่วยงานออกใบรับรองที่ถูกที่สุด เพื่อตอบสนองต่อเรื่องนี้ หน่วยงานออกใบรับรองจึงลดราคาและยกเลิกการตรวจสอบความถูกต้องที่มีราคาแพงกว่า ซึ่งเรียกว่าการแข่งขันสู่จุดต่ำสุด (Race to the Bottom ) การแข่งขันสู่จุดต่ำสุดนี้ได้รับการแก้ไขบางส่วนด้วย ใบรับรอง การตรวจสอบความถูกต้องแบบขยาย (Extended Validation: EV)แต่คุณค่าความน่าเชื่อถือในสายตาของผู้เชี่ยวชาญด้านความปลอดภัยกำลังลดลง^{[ 25 ]}ตามที่ปีเตอร์ กุตมันน์กล่าว ใบรับรอง EV ไม่ได้เพิ่มการควบคุมความปลอดภัยเพิ่มเติมใดๆ แต่ใบรับรอง EV เพียงแต่ฟื้นฟูผลกำไรของหน่วยงานออกใบรับรองให้กลับสู่ระดับก่อนการแข่งขันสู่จุดต่ำสุด โดยอนุญาตให้หน่วยงานออกใบรับรองเรียกเก็บเงินมากขึ้นสำหรับบริการที่พวกเขาควรจะให้บริการมาโดยตลอด^{[ 4 ]}การแข่งขันสู่จุดต่ำสุดนี้ยังได้รับการแก้ไขบางส่วนด้วยหน่วยงานออกใบรับรองเช่นLet's Encryptที่ให้ใบรับรองฟรี^{[ 26 ]} Let's Encrypt ยังกลายเป็นผู้ให้บริการใบรับรองรายใหญ่ที่สุด โดยมีเว็บไซต์มากกว่า 500 ล้านเว็บไซต์ที่ใช้งานอยู่^{[ 27 ] [ 28 ]}
• หน่วยงานรับรองพยายามปฏิเสธการรับประกันเกือบทั้งหมดแก่ผู้ใช้และฝ่ายที่พึ่งพาในคำแถลงการปฏิบัติการรับรอง (CPS) ของตน ตัวอย่างเช่นApple Incระบุใน CPS ของตนว่า "ในขอบเขตที่กฎหมายที่เกี่ยวข้องอนุญาต ข้อตกลงผู้สมัครสมาชิก หากมี จะปฏิเสธการรับประกันจาก Apple รวมถึงการรับประกันความสามารถในการขายหรือความเหมาะสมสำหรับวัตถุประสงค์เฉพาะ" ^{[ 29 ]}
• ตามที่ปีเตอร์ กุตมันน์กล่าวไว้ว่า "ผู้ใช้ใช้โปรโตคอลคำขอรับรองที่ไม่ระบุเพื่อรับใบรับรองซึ่งเผยแพร่ในตำแหน่งที่ไม่ชัดเจนในไดเร็กทอรีที่ไม่มีอยู่จริงโดยไม่มีวิธีการเพิกถอนที่แท้จริง" ^{[ 21 ]}
• เช่นเดียวกับธุรกิจทั้งหมด CA อยู่ภายใต้เขตอำนาจทางกฎหมายที่ตนดำเนินงานอยู่ และอาจถูกบังคับตามกฎหมายให้ประนีประนอมผลประโยชน์ของลูกค้าและผู้ใช้ของตน หน่วยงานข่าวกรองยังได้ใช้ใบรับรองปลอมที่ออกผ่านการประนีประนอมนอกกฎหมายของ CA เช่นDigiNotarเพื่อดำเนินการโจมตีแบบ man-in-the-middleอีกตัวอย่างหนึ่งคือคำขอเพิกถอน CA ของรัฐบาลเนเธอร์แลนด์ เนื่องจากกฎหมายของเนเธอร์แลนด์ที่ผ่านในปี 2018 ซึ่งให้อำนาจใหม่แก่หน่วยงานข่าวกรองและความมั่นคงของเนเธอร์แลนด์^{[ 30 ]}

การนำไปใช้งานมักมีข้อบกพร่องด้านการออกแบบ บั๊ก การตีความมาตรฐานที่แตกต่างกัน และการขาดความสามารถในการทำงานร่วมกันของมาตรฐานต่างๆ ปัญหาบางประการได้แก่:

• การใช้งานหลายๆ อย่างมักปิดใช้งานการตรวจสอบการเพิกถอน:
  • เนื่องจากมองว่าเป็นอุปสรรค นโยบายจึงไม่ได้รับการบังคับใช้
  • หากเปิดใช้งานฟังก์ชันนี้ในทุกเบราว์เซอร์โดยค่าเริ่มต้น รวมถึงการลงนามรหัส อาจทำให้โครงสร้างพื้นฐานล่มได้
• โครงสร้างข้อมูลแบบโดเมน (DNs) มีความซับซ้อนและเข้าใจยาก (ขาดรูปแบบมาตรฐาน ปัญหาด้านการรองรับหลายภาษา)
• rfc822Name มีสัญลักษณ์สองแบบ
• ข้อจำกัดด้านชื่อและนโยบายแทบจะไม่ได้รับการสนับสนุน
• ระบบจะไม่สนใจการใช้งานคีย์ และใช้ใบรับรองแรกในรายการแทน
• การบังคับใช้ OID ที่กำหนดเองนั้นเป็นเรื่องยาก
• ไม่ควรทำให้แอตทริบิวต์มีความสำคัญมากเกินไป เพราะจะทำให้โปรแกรมไคลเอนต์ทำงานผิดพลาด
• ความยาวของแอตทริบิวต์ที่ไม่ระบุไว้จะนำไปสู่ข้อจำกัดเฉพาะของผลิตภัณฑ์
• มีข้อผิดพลาดในการใช้งาน X.509 ที่อนุญาตให้มีการปลอมแปลงชื่อหัวเรื่องโดยใช้สตริงที่ลงท้ายด้วยค่าว่าง^{[ 31 ]}หรือ การโจมตี ด้วยการแทรกโค้ดในใบรับรอง
• โดยการใช้ ซับไอ เดนไทเตอร์ที่มีการเติม 0x80 ที่ผิดกฎหมาย ^{[ 32 ]}การใช้งานที่ไม่ถูกต้อง หรือโดยการใช้การล้นจำนวนเต็มของเบราว์เซอร์ของไคลเอนต์ ผู้โจมตีสามารถรวมแอตทริบิวต์ที่ไม่รู้จักไว้ใน CSR ซึ่ง CA จะลงนาม ซึ่งไคลเอนต์ตีความผิดว่าเป็น "CN" (OID=2.5.4.3) Dan Kaminskyได้สาธิตสิ่งนี้ในการประชุม Chaos Communication Congress ครั้งที่ 26 ใน หัวข้อ "Black OPs of PKI" ^{[ 33 ]}

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

• ใบรับรองที่ใช้ MD2ถูกนำมาใช้เป็นเวลานานและมีความเสี่ยงต่อการโจมตีแบบ preimageเนื่องจากใบรับรองหลักมีลายเซ็นของตนเองอยู่แล้ว ผู้โจมตีจึงสามารถใช้ลายเซ็นนี้กับใบรับรองระดับกลางได้
• ในปี พ.ศ. 2548 Arjen Lenstraและ Benne de Weger ได้สาธิต "วิธีการใช้การชนกันของแฮชเพื่อสร้างใบรับรอง X.509 สองใบที่มีลายเซ็นเหมือนกันและแตกต่างกันเฉพาะในคีย์สาธารณะ" ซึ่งทำได้โดยใช้การโจมตีการชนกันบนฟังก์ชันแฮชMD5 ^{[ 34 ]}
• ในปี 2551 Alexander Sotirovและ Marc Stevens ได้นำเสนอการโจมตีเชิงปฏิบัติที่Chaos Communication Congressซึ่งทำให้พวกเขาสามารถสร้าง Certificate Authority ปลอมที่ได้รับการยอมรับจากเบราว์เซอร์ทั่วไปทั้งหมดได้ โดยใช้ประโยชน์จากข้อเท็จจริงที่ว่า RapidSSL ยังคงออกใบรับรอง X.509 ที่ใช้ MD5 อยู่^{[ 35 ]}
• ในเดือนเมษายน พ.ศ. 2552 ในการประชุม Eurocrypt ^{[ 36 ]}นักวิจัยชาวออสเตรเลียจากมหาวิทยาลัย Macquarie ได้นำเสนอ "การค้นหาเส้นทางความแตกต่างอัตโนมัติสำหรับSHA-1 " ^{[ 37 ]}นักวิจัยสามารถสรุปวิธีการที่เพิ่มโอกาสในการชนกันได้หลายลำดับขนาด^{[ 38 ]}
• ในเดือนกุมภาพันธ์ พ.ศ. 2560 กลุ่มนักวิจัยที่นำโดย Marc Stevens ได้ทำการชนกันของ SHA-1 ซึ่งแสดงให้เห็นถึงจุดอ่อนของ SHA-1 ^{[ 39 ]}

การใช้ประโยชน์จากการชนกันของแฮชเพื่อปลอมลายเซ็น X.509 จำเป็นต้องให้ผู้โจมตีสามารถคาดเดาข้อมูลที่หน่วยงานออกใบรับรองจะลงนามได้ ซึ่งสามารถบรรเทาลงได้บ้างโดยที่หน่วยงานออกใบรับรองสร้างส่วนประกอบแบบสุ่มในใบรับรองที่ลงนาม โดยทั่วไปคือหมายเลขซีเรียล ฟอรัม CA/Browserได้กำหนดให้ต้องมีเอนโทรปีของหมายเลขซีเรียลในส่วนข้อกำหนดพื้นฐาน 7.1 ตั้งแต่ปี 2011 ^{[ 40 ]}

ตั้งแต่วันที่ 1 มกราคม 2559 ข้อกำหนดพื้นฐานห้ามการออกใบรับรองโดยใช้ SHA-1 ในช่วงต้นปี 2560 Chrome ^{[ 41 ]}และ Firefox ^{[ 42 ]}ปฏิเสธใบรับรองที่ใช้ SHA-1 ในเดือนพฤษภาคม 2560 ทั้ง Edge ^{[ 43 ]}และ Safari ^{[ 44 ]}ก็ปฏิเสธใบรับรอง SHA-1 เช่นกันOpenSSLเริ่มปฏิเสธใบรับรอง SHA-1 เป็นค่าเริ่มต้นในเวอร์ชัน 3.0 ซึ่งวางจำหน่ายในเดือนกันยายน 2564 ^{[ 45 ]}

• PKCS7 (มาตรฐานไวยากรณ์ข้อความเข้ารหัสลับ — คีย์สาธารณะพร้อมหลักฐานยืนยันตัวตนสำหรับข้อความที่ลงนามและ/หรือเข้ารหัสสำหรับ PKI) ^{[ ​​46 ]}
• Transport Layer Security (TLS) และ SSL ซึ่งเป็นโปรโตคอลการเข้ารหัสสำหรับการสื่อสารที่ปลอดภัยบนอินเทอร์เน็ต^{[ 47 ]}
• โปรโตคอลสถานะใบรับรองออนไลน์ (OCSP) ^{[ 48 ]} / รายการเพิกถอน ใบรับรอง (CRL) ^{[ 9 ]}  — นี่คือการตรวจสอบสถานะการเพิกถอนใบรับรอง
• PKCS12 (มาตรฐานไวยากรณ์การแลกเปลี่ยนข้อมูลส่วนบุคคล) — ใช้สำหรับจัดเก็บคีย์ส่วนตัวพร้อมใบรับรองคีย์สาธารณะที่เหมาะสม^{[ 49 ]}
• RFC  4158 — การสร้างเส้นทางการรับรอง — คำแนะนำและข้อเสนอแนะสำหรับการสร้างเส้นทางการรับรองกุญแจสาธารณะ X.509 ภายในแอปพลิเคชัน (เช่น การตรวจสอบความถูกต้องของใบรับรองปลายทางโดยใช้ใบรับรอง CA)

ในปี พ.ศ. 2538 คณะทำงานด้านวิศวกรรมอินเทอร์เน็ตร่วมกับสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ^{[ 50 ]}ได้จัดตั้งกลุ่มทำงานโครงสร้างพื้นฐานกุญแจสาธารณะ (X.509) กลุ่มทำงานนี้ซึ่งสิ้นสุดลงในเดือนมิถุนายน พ.ศ. 2557 ^{[ 51 ]}มักถูกเรียกว่า "PKIX" โดยได้จัดทำRFCและเอกสารมาตรฐานอื่นๆ เกี่ยวกับการใช้งานและปรับใช้ X.509 ในทางปฏิบัติ โดยเฉพาะอย่างยิ่งได้จัดทำRFC 3280และ RFC 5280 ซึ่งเป็นรุ่นต่อมา โดยกำหนดวิธีการใช้ X.509 ในโปรโตคอลอินเทอร์เน็ต  

TLS/SSLและHTTPSใช้ มาตรฐาน RFC 5280ของ X.509 เช่นเดียวกับS/MIME (Secure Multipurpose Internet Mail Extensions) และ วิธีการ EAP-TLSสำหรับการตรวจสอบสิทธิ์ WiFi โปรโตคอลใดๆ ที่ใช้ TLS เช่น SMTP, POP, IMAP, LDAP, XMPPและอื่นๆ อีกมากมาย ล้วนใช้ X.509 โดยปริยาย  

IPsecสามารถใช้ โปรไฟล์ RFC 4945สำหรับการตรวจสอบความถูกต้องของคู่ค้าได้  

ข้อกำหนดด้านความปลอดภัยของ OpenCableได้กำหนดโปรไฟล์ X.509 ของตนเองสำหรับการใช้งานในอุตสาหกรรมสายเคเบิล

อุปกรณ์ต่างๆ เช่นสมาร์ทการ์ดและTPMมักมีใบรับรองเพื่อระบุตัวตนของอุปกรณ์หรือเจ้าของ ใบรับรองเหล่านี้อยู่ในรูปแบบ X.509

มาตรฐาน WS -Securityกำหนดการตรวจสอบสิทธิ์ผ่าน TLS หรือผ่านโปรไฟล์ใบรับรองของตนเอง^{[ 18 ]}ทั้งสองวิธีใช้ X.509

ระบบ การลงนามรหัส Microsoft Authenticodeใช้ X.509 เพื่อระบุผู้เขียนโปรแกรมคอมพิวเตอร์คุณสมบัติSecure Boot ของ UEFIใช้ X.509 เพื่อตรวจสอบความถูกต้องของไดรเวอร์ UEFI หรือบูตโหลดเดอร์ระหว่างการบูตและไม่อนุญาตให้ใช้ไดรเวอร์หรือบูตโหลดเดอร์ที่อยู่ในรายการบล็อก (โดยใช้ Forbidden Key Exchange หรือฐานข้อมูล dbx) ^{[ 52 ]}

มาตรฐานการสื่อสารระบบอัตโนมัติทางอุตสาหกรรม OPC UAใช้มาตรฐาน X.509

โดยทั่วไป SSHใช้ โมเดลความปลอดภัยแบบ Trust On First Useและไม่จำเป็นต้องใช้ใบรับรอง อย่างไรก็ตาม การใช้งาน OpenSSH ที่ได้รับความนิยมนั้น รองรับโมเดลข้อมูลประจำตัวที่ลงนามโดย CA โดยอิงตามรูปแบบใบรับรองที่ไม่ใช่ X.509 ของตัวเอง^{[ 53 ]}

• สัญกรณ์ไวยากรณ์นามธรรมหนึ่ง
• นโยบายใบรับรอง
• การรักษาความปลอดภัยการเข้าถึงรหัส
• ความปลอดภัยในการสื่อสาร
• ความปลอดภัยของข้อมูล
• ISO/IEC JTC 1
• โปรโตคอลการสอบถามทรัพยากร PKI
• การเข้ารหัสแบบกุญแจสาธารณะ
• โครงสร้างพื้นฐานกุญแจสาธารณะ
• โปรโตคอลการประทับเวลา
• การประทับเวลาที่เชื่อถือได้
• เอ็ดดีเอสเอ

• มาตรฐาน X.509 ของ ITU-T
• บทความของปีเตอร์ กุตมันน์:
  • ภาพรวมของ PKI
  • หมายเหตุเกี่ยวกับการใช้งาน X.509 และคู่มือรูปแบบ
• "คำถามที่พบบ่อยเกี่ยวกับคริปโตเคอร์เรนซีจาก RSA Labs" RSA Laboratories. เก็บถาวรจากต้นฉบับเมื่อวันที่ 30 ธันวาคม 2549
• แนวทางการเขียนโค้ดที่ปลอดภัยของ Sun
• RFC  4158 – " โครงสร้างพื้นฐานกุญแจสาธารณะ X.509 บนอินเทอร์เน็ต: การสร้างเส้นทางการรับรอง " ข้อมูลทั่วไป
• RFC  5280 – " โปรไฟล์ใบรับรองโครงสร้างพื้นฐานกุญแจสาธารณะ X.509 ของอินเทอร์เน็ตและรายการเพิกถอนใบรับรอง (CRL) " มาตรฐานที่เสนอ
• ทำความเข้าใจเกี่ยวกับใบรับรองดิจิทัล Microsoft TechNet