Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
ในการเข้ารหัสข้อมูล X.509 เป็นรูปแบบมาตรฐาน ITU-T สำหรับโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) และโครงสร้างพื้นฐานการจัดการสิทธิ์ (PMI) ซึ่ง X.509 จะระบุหลากหลายหมวดหมู่ รูปแบบมาตรฐานสำหรับใบรับรองกุญแจสาธารณะ รายการเพิกถอนใบรับรอง ใบรับรอง attribute และขั้นตอนการตรวจสอบเส้นทางการรับรอง
X.509 ถูกออกมาใช้ในวันที่ 3 กรกฎาคม พ.ศ. 2531 และมีความเกี่ยวข้องกับมาตรฐาน X.500 ซึ่งก็ถือว่าเป็นระบบลำดับชั้นที่เข้มงวดของผู้มีอำนาจในการออกใบรับรอง (CAs) ในการออกใบรับรอง ซึ่งแตกต่างจากเว็บรูปแบบของความไว้วางใจเว็บ (Web of trust model) ยกตัวอย่างเช่น PGP ที่ทุกคน (ที่ไม่ใช่เพียงแค่ CAs) ซึ่งอาจจะลงนามและเป็นเครื่องยืนยันถึงความถูกต้องของใบรับรองของผู้อื่น รุ่นที่ 3 ของ X.509 จะรวมไปทั้งความยืดหยุ่นของโครงสร้างอื่นๆ เช่น bridge และ mesh เป็นต้น มันสามารถนำใช้แบบ Peer-to-Peer แต่แทบจะไม่เคยถูกใช้ ระบบ X.500 ถูก implement โดยประเทศอธิปไตย เพื่อบอกข้อมูลประจำตัวร่วมกันเพื่อบรรลุสนธิสัญญาร่วมกัน และ โครงสร้างพื้นฐานกุญแจสาธารณะของ IETF (X.509) หรือ PKIX คณะทำงานได้ทำการปรับมาตรฐานให้กับองค์กรที่มีความยืดหยุ่นมากขึ้นของอินเทอร์เน็ต ในความเป็นจริงใบรับรอง X.509 มักจะหมายถึง IETF ของใบรับรอง PKIX และข้อมูลส่วนตัว CRL ของมาตรฐานใบรับรอง X.509 version 3 ตามที่ระบุไว้ใน RFC 5280 ปกติจะเรียกว่า PKIX สำหรับระบบโครงสร้างพื้นฐานกุญแจสาธารณะ
ในระบบ 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 จะเป็นดังนี้
การขยายแต่ละครั้งจะมี 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 คือ:
โดยทั่วไป ถ้าใบรับรองมีส่วนต่อขยายหลายส่วนของข้อจำกัดการใช้งาน ทุกคนต้องมีความพึงพอใจสำหรับการใช้งานที่กำหนดให้ตามความเหมาะสม RFC 5280 ให้ตัวอย่างที่เฉพาะเจาะจงของใบรับรองที่มีทั้ง keyUsage และ extendedKeyUsage ในกรณีนี้ทั้งคู่จะต้องได้รับการประมวลผลและใบรับรองที่สามารถนำมาใช้เฉพาะในกรณีที่ส่วนต่อขยายของทั้งสองมีความเกี่ยวข้องกันในการระบุการใช้งานของใบรับรอง
ชื่อไฟล์ทั่วไปของส่วนต่อขยายใบรับรอง X.509 คือ
PKCS#7 เป็นมาตรฐานสำหรับการลงนามหรือการเข้ารหัสข้อมูล (เรียกอย่างเป็นทางการ "ห่อ") ตั้งแต่ใบรับรองจำเป็นในการตรวจสอบลงนามข้อมูลก็เป็นไปได้ที่รวมไว้ในโครงสร้าง SignedData ไฟล์ .P7C เป็น degenerated โครงสร้าง SignedData โดยไม่มีข้อมูลใดๆที่จะลงนาม
PKCS#12 วิวัฒนาการมาจากมาตรฐานการแลกเปลี่ยนข้อมูลส่วนบุคคล (PFX) และถูกนำมาใช้ในการแลกเปลี่ยนข้อมูลส่วนตัวและสาธารณะในไฟล์เดียว
A certificate chain (ดูแนวคิดเทียบเท่าของ "เส้นทางการรับรอง" ที่กำหนดโดย RFC 5280) เป็นรายการของใบรับรอง (โดยปกติจะเริ่มต้นด้วยการรับรองจากนิติบุคคล) ตามด้วยใบรับรอง CA (โดยปกติจะเป็นคนสุดท้ายที่ถูกลงนามด้วยตนเองในใบรับรอง) ที่มีคุณสมบัติดังต่อไปนี้
1. ผู้ออกแต่ละใบรับรอง (ยกเว้นคนสุดท้าย) ตรงกับหัวข้อใบรับรองถัดไปในรายการ 2. แต่ละใบรับรอง (ยกเว้นคนสุดท้าย) ควรจะได้รับการลงนามโดยคีย์ลับที่สอดคล้องกับใบรับรองต่อไปในห่วงโซ่ (เช่นลายเซ็นของใบรับรองหนึ่งใบสามารถตรวจสอบได้โดยใช้กุญแจสาธารณะที่มีอยู่ในใบรับรองดังต่อไปนี้) 3. ใบรับรองสุดท้ายในรายการต้องวางใจได้ ใบรับรองที่คุณไว้วางใจเพราะมันถูกส่งถึงคุณโดยบางขั้นตอนที่น่าเชื่อถือ
Certificate chains ถูกใช้เพื่อที่ตรวจสอบว่ากุญแจสาธารณะ (PK) ที่มีอยู่ในใบรับรองเป้าหมาย (ใบรับรองแรกใน chain) และข้อมูลอื่น ๆ ที่มีอยู่ในนั้นได้อย่างมีประสิทธิภาพ เพื่อที่ตรวจสอบให้แน่ใจว่าลายเซ็นบนใบรับรองเป้าหมายถูกรับรองโดยกุญแจสาธารณะ (PK) ที่มีอยู่ในใบรับรองดังกล่าว ซึ่งลายเซ็นถูกตรวจสอบโดยใช้ใบรับรองถัดไปจนถึงใบรับรองใบสุดท้าย ในขณะที่ใบรับรองสุดท้ายเป็นใบรับรองที่ไว้ใจได้ สุดท้ายมันจะพิสูจน์ว่าใบรับรองเป้าหมายสามารถเชื่อถือได้
คำอธิบายในวรรคก่อนหน้าเป็นมุมมองที่ง่ายในการตรวจสอบกระบวนการเส้นทางในใบรับรองตามที่กำหนดโดย RFC 5280 ซึ่งเกี่ยวกับการตรวจสอบเพิ่มเติม เช่นตรวจสอบความถูกต้องของวันที่ในใบรับรอง เป็นต้น
แม้ว่าใบรับรอง X.509 สามารถมีผู้ออกไดเพียงคนเดียว (ไม่สามารถมีลายเซ็น CA มากกว่า 1 ลายเซ็น) ซึ่งต่างจาก certificate chains สามารถมีอยู่สำหรับใบรับรองเป้าหมายเพราะว่าใบรับมากกว่า 1 ใบสามารถมีกุญแจสาธารณะเหมือนกันได้ นี่คือสิ่งสำคัญสำหรับ cross-certification ระหว่าง PKI ที่แตกต่างกันและการใช้งานอื่นๆ ดังตัวอย่างต่อไปนี้
{{}}===ตัวอย่างที่ 1 Cross-certification ที่ระดับ CA หลัก ระหว่างโครงสร้างกุญแจสาธารณะ===
นอกเหนือจาก "cert2.2 → cert2" ทางออก certificate chain ลำดับ 2 ที่ถูกต้องสำหรับ cert2.2 แล้ว "cert2.2 → cert2.1 → cert1" ซึ่งช่วยให้ cert2.2 (ออกโดย PKI 2) สามารถเชื่อถือได้โดย PKI 1
เพื่อให้การเปลี่ยนแปลงที่สง่างามจากคู่กุญแจลงนามแบบเก่าไปสู่แบบใหม่ CA ควรออกใบรับรองซึ่งมีกุญแจสาธารณะเก่าที่ถูกลงนามโดยกุญแจลงนามส่วนตัวใหม่และใบรับรองที่ประกอบด้วยกุญแจสาธารณะแบบใหม่ซึ่งลงนามโดยกุญแจลงนามส่วนตัวแบบใหม่ ทั้งคู่เป็นตัวออกใบรับรองเองแต่ไม่ได้ลงนามเอง
เนื่องจากทั้ง cert1 และ cert3 มีกุญแจสาธารณะเดียวกัน (เก่า) มี 2 certificate chains ที่ถูกต้องสำหรับ cert5 "cert5 → cert1" and "cert5 → cert3 → cert2" และ analogously สำหรับ cert6 นี่จะช่วยใช้ใบรับรองผู้ใช้เก่า (เช่น cert5) และใบรับรองใหม่ (เช่น cert6) สามารถเชื่อถือได้โดยบุคคลที่มีใบรับรอง root CA ใหม่หรือเก่า เป็นที่ไว้วางใจในช่วงการเปลี่ยนแปลงไปเป็นกุญแจ CA ใหม่
นี่คือตัวอย่างใบรับรอง X.509 ที่ผ่านการเข้ารหัสของ www.freesoft.org สร้างโดย OpenSSL เป็นใบรับรองขนาก 1kB มันถูกออกโดย Thawte (ตั้งแต่ได้มาโดย VeriSign และในปัจจุบัน Symantec เป็นเจ้าของ) เรื่องของมันประกอบด้วยรายละเอียดส่วนบุคคลจำนวนมากแต่ส่วนที่สำคัญที่สุดมักจะเป็นชื่อทั่วไป (CN) ซึ่งส่วนนี้ต้องเข้ากับโฮสต์ที่ได้รับการรับรอง รวมทั้งเป็นกุญแจสาธารณะ RSA (โมดูลัสและสัญลักษณ์สาธารณะ) ตามด้วยลายเซ็น คำนวณโดยการทำ Hash MD5 ของส่วนแรกในใบรับรองและการลงนาม (ประยุกต์กับกระบวนการการเข้ารหัส) โดยกุญแจส่วนตัว RSA ของ Thawte
ในการตรวจสอบใบรับรอง ใบรับรองต้องการใบรับรองลำดับที่ 2 เข้ากับผู้ออกใบรับรองลำดับที่ 1 (Thawte Server CA) ลำดับแรกใบรับรองตรวจสอบว่าใบรับรองลำดับที่ 2 คือประเภทของ CA นั่นหมายความว่ามันสามารถนำมาใช้ในการออกใบรับรองอื่นๆ โดยจะทำการตรวจสอบค่า attribute ของ CA ในส่วนต่อขยาย X.509 เวอร์ชัน 3 ดังนั้นกุญแจสาธารณะ RSA จากใบรับรอง CA จะถูกใช้ในการถอดรหัสลายเซ็นบนใบรับรองแรกที่ได้รับการ Hash MD5 ซึ่งต้องเข้ากับ Hash MD5 จริงที่ถูกคำนวณในส่วนที่เหลือของใบรับรอง
นี่คือตัวอย่างของใบรับรองที่ลงนามด้วยตัวเอง ในฐานะผู้ออกใบรับรองเช่นกัน ไม่มีวิธีการตรวจสอบใบรับรองยกเว้นตรวจสอบด้วยตัวมันเอง Thawte เป็นหนึ่งใน root certificate authorities ที่ได้รับการยอมรับจาก Microsoft และ Netscape ใบรับรองนี้มาพร้อมกับเว็บเบราว์เซอร์และเป็นที่ถือเชื่อถือได้โดยปริยาย ในตลอดการใช้งานโดยทั่วไปเชื่อถือใบรับรองซึ่งลงนามรับรองได้ (ตามที่มีในข้อจำกัดเบื้องต้นของ X.509 เวอร์ชัน 3) ซึ่งมันต้องเข้ากับกุญแจส่วนตัวที่ต้องดูแลรักษาอย่างใกล้ชิด
มีการค้นพบปัญหาเกี่ยวกับโครงสร้างกุญแจสาธารณะ (PKI) โดย Bruce Schneier Peter Gutmann และผู้เชี่ยวชาญด้านความปลอดภัยคนอื่นๆ
ผู้ใช้อินเทอร์เน็ตส่วนใหญ่ทั้งภาคธุรกิจและภาคสังคมขาดความสามารถพื้นฐานในความรู้และความเข้าใจในการเข้ารหัสข้อมูลเพื่อระงับการคุกคาม ความซับซ้อนนี้เป็นหนึ่งในจุดอ่อนของการเข้ารหัสกุญแจสาธารณะ ซึ่งไม่เป็นมิตรกับผู้ใช้และการใช้งานโดยรวมจึงมีผลกระทบกับประสิทธิภาพในการแก้ปัญหา เพื่อที่จะจัดการปัญหาดังกล่าว บริษัทซอฟต์แวร์รายใหญ่ได้รวบรวม root certificate ที่ได้รับการตรวจสอบเพื่อความปลอดภัยเข้าไปใน browser ผู้ใช้และระบบปฏิบัติการ เพื่อประโยชน์ในการใช้งานง่ายและการทำงานร่วมกัน ทุกเว็บเบราว์เซอร์และระบบปฏิบัติการในปัจจุบันใส่ใบรับรองทีได้การตรวจสอบ Trusted Root Store ของที่ออกใบรับรอง ใบรับรองที่ออกโดยองค์กรเหล่านี้หรือภายใต้องค์กรเหล่านี้ได้รับความเชื่อถือโดยอาศัยหน่วยงานเหล่านี้ถือว่าเชื่อถือได้และปลอภัยอย่างอัตโนมัติ เมื่อเทียบกับใบรับรองที่ออกโดยบุคคลที่ไม่รู้จัก ซึ่งจะเตือนว่าไม่น่าไว้วางใจ ทั้งหมดนี้ตีความลงในใบรับรองที่ออกโดยเจ้าหน้าที่ทั้งหมดซึ่งไม่รวมอยู่กับ root store วิธีการนี้พยายามที่จะทำข้อกำหนดของระบบความปลอดภัยอัตโนมัติและมีความโปร่งใส และที่สำคัญเอาออกจากผู้ใช้ การตัดสินใจสร้างกระบวนการเกี่ยวกับความน่าเชื่อถือของเว็บไซต์
มาตรฐาน X.509 ได้รับการออกแบบมาเพื่อรองรับโครงสร้าง X.500 แต่การใช้งานในวันนี้ cases center บริเวณรอบๆเว็บไซต์ คุณสมบัติหลายอย่างมีน้อยและไม่เกี่ยวข้องในทุกวันนี้ ข้อกำหนด X.509 มาจากการเป็นมากกว่าการทำงานและข้อมูลบรรทัดฐานจะถูกกระจายไปทั่วเอกสารจากส่วนมาตรฐานต่างๆ โปรไฟล์หลายคนได้รับการพัฒนาเพื่อแก้ปัญหานี้ แต่แนะนำปัญหาการทำงานร่วมกันและไม่ได้แก้ไขปัญหา
ปัญหาการใช้งานเกิดจากข้อบกพร่องในการออกแบบ bugs การตีความที่แตกต่างกันของมาตรฐาน และขาดการทำงานร่วมกันของมาตรฐานที่ต่างกัน ปัญหาคือ
เจ้าหน้าที่ใบรับรอง (CA) เป็นนิติบุคคลที่ออกใบรับรองดิจิทัลสำหรับการใช้งานโดยบุคคลอื่นๆ มันเป็นตัวอย่างของบุคคลที่สามที่เชื่อถือได้ CA มีลักษณะของหลายแผนการโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI)
มีหลาย CA เชิงพาณิชย์คิดค่าบริการ สถาบันการศึกษาและหน่วยงานรัฐบาลอาจมี CAs ของตัวและ CAs ฟรี
การทำงานกลุ่มโครงสร้างพื้นฐานกุญแจสาธารณะ X.509 (PKIX) เป็นกลุ่มทำงานของ the Internet Engineering Task Force (IETF) ทุ่มเทเพื่อสร้าง RFCs และเอกสารมาตรฐานอื่นๆ ในประเด็นที่เกี่ยวกับโครงสร้างพื้นฐานกุญแจสาธารณะของใบรับรอง X.509 PKIX ก่อตั้งในช่วงฤดูใบไม้ร่วงปี 2538 ร่วมสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ คณะทำงานถูกปิดลงในพฤศจิกายน 2556
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
