ใบรับรอง ของ X.509

ในระบบ X.509 ผู้มีอำนาจออกใบรับรองจะออกใบรับรองที่เกี่ยวพันกับกุญแจสาธารณะที่มีชื่อแตกต่างกันในรูปแบบ X.500 หรือชื่ออื่นๆ เช่น e-mail หรือ DNS

ใบรับรองหลักที่น่าเชื่อถือขององค์กรสามารถแจกจ่ายไปยังให้กับพนักงานทุกคนเพื่อให้พวกเขาสามารถระบบ PKI ขององค์กร เบราว์เซอร์ เช่น Internet Explorer Firefox Opera Safari และ Chrome มาพร้อมกับชุดที่กำหนดไว้ของใบรับรองหลัก ดังนั้นใบรับรอง SSL จากผู้ขายรายใหญ่จะทำงานทันที ซึ่งมีผลกับนักพัฒนาเบราว์เซอร์ตรวจสอบ CAs ที่ได้รับความเชื่อถือบุคคลที่ 3 สำหรับเบราว์เซอร์ผู้ใช้

X.509 ยังรวมไปถึงการ implememt มาตรฐานสำหรับรายการเพิกถอนใบรับรอง (CRL) ซึ่งมักจะเพิกเฉยระบบโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) วิธีรับรอง IETF ในการตรวจสอบความถูกต้องของใบรับรองเป็นโพรโทคอลสถานะของใบรับรองออนไลน์ (OCSP) Firefox 3 ให้ OCSP ตรวจสอบโดยค่าเริ่มต้นของ Windows แต่ละรุ่น รวมไปถึง Vista และอื่นๆต่อมา

โครงสร้างของใบรับรอง

โครงสร้างเล็งเห็นตามมาตรฐานจะถูกแสดงในภาษาที่เป็นทางการคือบทคัดย่อไวยากรณ์

โครงสร้างของใบรับรองดิจิทัล X.509 v3 จะเป็นดังนี้

  • ใบรับรอง
    • รุ่นของใบรับรอง
    • หมายเลขลำดับ
    • Algorithm ID
    • ผู้ออกใบรับรอง
    • ความถูกต้อง
      • Not Before
      • Not After
    • หัวข้อ
    • หัวข้อข้อมูลกุญแจสาธารณะ
      • Algorithm กุญแจสาธารณะ
      • หัวข้อกุญแจสาธารณะ
    • ผู้ออกตัวเอกลักษณ์ (ถ้ามี)
    • หัวข้อตัวเอกลักษณ์ (ถ้ามี)
    • ส่วนขยาย (ถ้ามี)
      • ...
  • Algorithm ลายเซ็นใบรับรอง
  • ลายเซ็นใบรับรอง

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

โครงสร้างของรุ่นที่ 1 ถูกระบุใน RFC 1422

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

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

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

ส่วนต่อขยายที่แจ้งการใช้งานที่เฉพาะเจาะจงของใบรับรอง

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

  • ข้อจำกัดพื้นฐาน { id-ce 19 } จะใช้ในการระบุใบรับรองว่าเป็นของ CA
  • การใช้คีย์ {id-CE 15} ให้บิตแมปที่ระบุการดำเนินการเข้ารหัสลับซึ่งอาจดำเนินการโดยใช้กุญแจสาธารณะที่มีอยู่ในใบรับรอง ยกตัวอย่างเช่น มันอาจแสดงให้เห็นว่ากุญแจควรใช้ในการรองชื่อรับรอง แต่ไม่ได้ใช้เข้ารหัส
  • การใช้คีย์ขยาย {id-CE 37} จะถูกใช้ในใบรับรองทั่วไปเพื่อระบุวัตถุประสงค์ของกุญแจสาธารณะที่มีอยู่ในใบรับรอง มันมีรายชื่อของ OIDs แต่ละแห่งซึ่งบ่งบอกการใช้งานที่ได้รับอนุญาต ตัวอย่างเช่น {id-PKIX 3 1} แสดงให้เห็นว่า กุญแจมักจะถูกใช้บนเซิฟเวอร์ของการเชื่อมต่อ TLS หรือ SSL {id-PKIX 3 4} แสดงให้เห็นว่ากุญแจถูกใช้เพื่อรักษาความปลอดภัยของอีเมล

โดยทั่วไป ถ้าใบรับรองมีส่วนต่อขยายหลายส่วนของข้อจำกัดการใช้งาน ทุกคนต้องมีความพึงพอใจสำหรับการใช้งานที่กำหนดให้ตามความเหมาะสม RFC 5280 ให้ตัวอย่างที่เฉพาะเจาะจงของใบรับรองที่มีทั้ง keyUsage และ extendedKeyUsage ในกรณีนี้ทั้งคู่จะต้องได้รับการประมวลผลและใบรับรองที่สามารถนำมาใช้เฉพาะในกรณีที่ส่วนต่อขยายของทั้งสองมีความเกี่ยวข้องกันในการระบุการใช้งานของใบรับรอง

ชื่อไฟล์ส่วนต่อขยายของใบรับรอง

ชื่อไฟล์ทั่วไปของส่วนต่อขยายใบรับรอง X.509 คือ

  • .pem - (Privacy-enhanced Electronic Mail) ใบรับรองเข้ารหัสแบบ Base64 DER อยู่ระหว่างส่วนหัวและส่วนท้ายของใบรับรอง
  • .cer, .crt, .der - มักอยู่ในรูปแบบ DER binary แต่ใบรับรองที่เข้ารหัสแบบ Base64 เป็นเรื่องปกติ (ดู .pem ด้านบน)
  • .p7b, .p7c - PKCS#7 โครงสร้าง SignedData ที่ไม่มีข้อมูล เพียงใบรับรอง หรือ CRL
  • .p12 - PKCS#12 อาจมีใบรับรอง (สาธารณะ) และกุญแจส่วนตัว (ป้องกันด้วยรหัสผ่าน)
  • .pfx - PFX ต้นแบบของ PKCS#12 (มักจะมีข้อมูลในรูปแบบ PKCS#12 เช่นเดียวกับ PFX ที่สร้างขึ้นใน IIS)

PKCS#7 เป็นมาตรฐานสำหรับการลงนามหรือการเข้ารหัสข้อมูล (เรียกอย่างเป็นทางการ "ห่อ") ตั้งแต่ใบรับรองจำเป็นในการตรวจสอบลงนามข้อมูลก็เป็นไปได้ที่รวมไว้ในโครงสร้าง SignedData ไฟล์ .P7C เป็น degenerated โครงสร้าง SignedData โดยไม่มีข้อมูลใดๆที่จะลงนาม

PKCS#12 วิวัฒนาการมาจากมาตรฐานการแลกเปลี่ยนข้อมูลส่วนบุคคล (PFX) และถูกนำมาใช้ในการแลกเปลี่ยนข้อมูลส่วนตัวและสาธารณะในไฟล์เดียว

ใกล้เคียง

X.509