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

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

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

โดยทั่วไปแล้ว ใบรับรองกุญแจสาธารณะจะถูกร้องขอจาก PKI โดยใช้CSRซึ่งจำเป็นต้องถ่ายโอนโดยใช้โปรโตคอลการลงทะเบียนใบรับรองที่ปลอดภัย เช่นCMP , ESTหรือACMEฝ่ายต่างๆ ที่เกี่ยวข้องในกระบวนการลงทะเบียนจะต้องตรวจสอบความถูกต้อง ความสมบูรณ์ และการอนุญาตของ CSR ซึ่งผู้ออกใบรับรองเป็นผู้รับผิดชอบหลัก

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

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

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

ใบรับรองระดับกลางมีวัตถุประสงค์คล้ายกับใบรับรองราก คือใช้เพื่อลงนามในใบรับรองอื่นเท่านั้น อย่างไรก็ตาม ใบรับรองระดับกลางไม่ได้ลงนามด้วยตนเอง ใบรับรองรากหรือใบรับรองระดับกลางอื่นจำเป็นต้องลงนามในใบรับรองนั้นด้วย

ใบรับรองปลายทางหรือใบรับรองใบคือ ใบรับรองใดๆ ที่ไม่สามารถลงนามในใบรับรองอื่นๆ ได้ ตัวอย่างเช่น ใบรับรองเซิร์ฟเวอร์และไคลเอ็นต์ TLS/SSL ใบรับรองอีเมล ใบรับรองการลงนามรหัส และใบรับรองที่ผ่านการรับรอง ล้วนเป็นใบรับรองปลายทางทั้งสิ้น

โปรโตคอลTransport Layer Security (TLS) รวมถึง โปรโตคอล Secure Sockets Layer (SSL) ซึ่งเป็นโปรโตคอลรุ่นเก่ากว่า ช่วยให้มั่นใจได้ว่าการสื่อสารระหว่างคอมพิวเตอร์ไคลเอ็นต์และเซิร์ฟเวอร์มีความปลอดภัย โปรโตคอลนี้กำหนดให้เซิร์ฟเวอร์ต้องแสดงใบรับรองดิจิทัลเพื่อพิสูจน์ว่าเป็นปลายทางที่ตั้งใจไว้ ไคลเอ็นต์ที่เชื่อมต่อจะทำการตรวจสอบความถูกต้องของเส้นทางการรับรองเพื่อให้มั่นใจว่า:

1. หัวข้อของใบรับรองจะต้องตรงกับชื่อโฮสต์ (อย่าสับสนกับชื่อโดเมน ) ที่ไคลเอ็นต์พยายามเชื่อมต่อ
2. ใบรับรองนี้ได้รับการลงนามโดยหน่วยงานออกใบรับรองที่เชื่อถือได้

The Subject field of the certificate must identify the primary hostname of the server as the Common Name. This means that the name listed in the certificate should exactly match the domain name users connect to (for example, www.example.com), ensuring that the certificate is valid for that specific hostname.^[5] The hostname must be publicly accessible, not using private addresses or reserved domains.^[6] A certificate may be valid for multiple hostnames (e.g., a domain and its subdomains). Such certificates are commonly called Subject Alternative Name (SAN) certificates or Unified Communications Certificates (UCC). These certificates contain the Subject Alternative Name field, though many CAs also put them into the Subject Common Name field for backward compatibility. If some of the hostnames contain an asterisk (*), a certificate may also be called a wildcard certificate.

Once the certification path validation is successful, the client can establish an encrypted connection with the server.

Internet-facing servers, such as public Web servers, must obtain their certificates from a trusted, public certificate authority (CA).

Client certificates authenticate the client connecting to a TLS service, for instance to provide access control. Because most services provide access to individuals, rather than devices, most client certificates contain an email address or personal name rather than a hostname. In addition, the certificate authority that issues the client certificate is usually the service provider to which client connects because it is the provider that needs to perform authentication.

While most web browsers support client certificates, the most common form of authentication on the Internet is a username and password pair. Client certificates are more common in virtual private networks (VPN) and Remote Desktop Services, where they authenticate devices.

In accordance with the S/MIME protocol, email certificates can both establish the message integrity and encrypt messages. To establish encrypted email communication, the communicating parties must have their digital certificates in advance. Each must send the other one digitally signed email and opt to import the sender's certificate.

Some publicly trusted certificate authorities provide email certificates, but more commonly S/MIME is used when communicating within a given organization, and that organization runs its own CA, which is trusted by participants in that email system.

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

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

ใบรับรอง Subject Alternative Name (SAN) เป็นส่วนขยายของX.509ที่อนุญาตให้เชื่อมโยงค่าต่างๆ กับใบรับรองความปลอดภัยโดยใช้subjectAltNameฟิลด์^{[ 7 ]}ค่าเหล่านี้เรียกว่าSubject Alternative Names (SANs) ชื่อต่างๆ ได้แก่: ^{[ 4 ] : §4.2.1.6}

• ที่อยู่อีเมล
• ที่อยู่ IP
• URI
• ชื่อ DNS : โดยปกติแล้วจะระบุเป็นชื่อทั่วไป (Common Name RDN)ในช่องหัวเรื่องของใบรับรองหลักด้วย
• ชื่อในสารบบ: ชื่อที่ระบุเป็นพิเศษ (Distinguished Name) ทางเลือก อื่นนอกเหนือ จากที่ระบุไว้ในหัวเรื่อง
• ชื่ออื่นๆ ที่กำหนดเป็นชื่อทั่วไปหรือชื่อหลักสากล : ตัวระบุวัตถุ ที่ลงทะเบียน แล้วตามด้วยค่า

ณ เดือนพฤษภาคม พ.ศ. 2543 Subject Alternative Names (SAN) เป็นวิธีการที่นิยมใช้ในการเพิ่มชื่อ DNS ลงในใบรับรอง^{[ 8 ]}วิธีการเดิมในการใส่ชื่อ DNS ในcommonNameฟิลด์นั้นถือว่าล้าสมัยแล้ว^{[ 9 ]} Google Chromeเวอร์ชัน 58 (มีนาคม พ.ศ. 2560) ได้ลบการสนับสนุนการตรวจสอบcommonNameฟิลด์ทั้งหมดออกไป โดยจะตรวจสอบเฉพาะ SAN เท่านั้น^{[ 9 ]} ดังแสดงในภาพส่วนของวิกิมีเดียทางด้านขวา ฟิลด์ SAN สามารถมีไวด์การ์ดได้^{[ 10 ]}ไม่ใช่ผู้จำหน่ายทุกรายที่สนับสนุนหรือรับรองการผสมไวด์การ์ดลงในใบรับรอง SAN ^{[ 11 ]}

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

ตัวอย่างเช่น ใบรับรองไวด์การ์ดเพียงใบเดียวhttps://*.example.comจะช่วยรักษาความปลอดภัยให้กับโดเมนย่อยทั้งหมดเหล่านี้บนhttps://*.example.comโดเมนหลัก:

• payment.example.com
• contact.example.com
• login-secure.example.com
• www.example.com

แทนที่จะขอใบรับรองแยกต่างหากสำหรับโดเมนย่อย คุณสามารถใช้ใบรับรองเดียวสำหรับโดเมนหลักและโดเมนย่อยทั้งหมดเพื่อลดต้นทุนได้^{[ 12 ]}

เนื่องจากไวลด์การ์ดครอบคลุมเพียงระดับเดียวของโดเมนย่อย (เครื่องหมายดอกจันไม่ตรงกับจุด) ^{[ 13 ]}โดเมนเหล่านี้จึงไม่ถูกต้องสำหรับใบรับรอง: ^{[ 14 ]}

• test.login.example.com
• example.com

โปรดทราบว่าอาจมีข้อยกเว้นบางประการจาก CA ต่างๆ ตัวอย่างเช่น ใบรับรอง wildcard-plus จาก DigiCert จะมีคุณสมบัติ "Plus" โดยอัตโนมัติสำหรับโดเมนexample.comหลัก

รองรับการจับคู่โดเมนย่อยเพียงระดับเดียวเท่านั้น^{[ 13 ] [ 15 ]}

ไม่สามารถขอไวลด์การ์ดสำหรับใบรับรองการตรวจสอบแบบขยายได้ [ ^{16 ] วิธี} แก้ปัญหาอาจเป็นการเพิ่มชื่อโฮสต์เสมือนทุกชื่อใน ส่วนขยาย Subject Alternative Name (SAN) ^{[ 17 ] [ 18 ]}ปัญหาหลักคือต้องออกใบรับรองใหม่ทุกครั้งที่มีการเพิ่มเซิร์ฟเวอร์เสมือนใหม่ (ดูTransport Layer Security § การสนับสนุนเซิร์ฟเวอร์เสมือนตามชื่อสำหรับข้อมูลเพิ่มเติม)

สามารถเพิ่มไวลด์การ์ดเป็นโดเมนในใบรับรองหลายโดเมนหรือใบรับรองการสื่อสารแบบรวม (UCC) นอกจากนี้ ไวลด์การ์ดเองก็สามารถมีsubjectAltNameส่วนขยายได้ รวมถึงไวลด์การ์ดอื่นๆ ตัวอย่างเช่น ใบรับรองไวลด์การ์ด*.wikipedia.orgมี*.m.wikimedia.orgSubject Alternative Name เป็นชื่อทางเลือก ดังนั้นจึงรักษาความปลอดภัยได้www.wikipedia.orgแม้กระทั่งชื่อเว็บไซต์ที่แตกต่างกันโดยmeta.m.wikimedia.orgสิ้นเชิง^{[ 19 ]}

RFC  6125คัดค้านใบรับรองไวลด์การ์ดด้วยเหตุผลด้านความปลอดภัย โดยเฉพาะ "ไวลด์การ์ดบางส่วน" ^{[ 20 ]}

สัญลักษณ์ไวด์การ์ดใช้ได้กับชื่อโดเมนเพียงระดับเดียวเท่านั้น*.example.comตรงกับsub1.example.comแต่ไม่ใช่example.comและไม่ใช่sub2.sub1.domain.com

ข้อกำหนดเบื้องต้น^{[ 8 ]}อนุญาตให้ไวลด์การ์ดปรากฏที่ใดก็ได้ภายในป้ายกำกับในฐานะ "ไวลด์การ์ดบางส่วน":

f*.domain.comโอเค มันจะเข้ากันได้frog.domain.comแต่ไม่frog.super.domain.com

baz*.example.netโอเคและตรงกันbaz1.example.net

*baz.example.netโอเคและตรงกันfoobaz.example.net

b*z.example.netโอเคและตรงกันbuzz.example.net

อย่างไรก็ตาม ไม่แนะนำให้ใช้ใบรับรอง "partial-wildcard" นับตั้งแต่ปี 2011 การสนับสนุน partial wildcard เป็นทางเลือก และถูกห้ามอย่างชัดเจนในส่วนหัว SubjectAltName ที่จำเป็นสำหรับใบรับรองแบบหลายชื่อ^{[ 21 ] : §6.3} เบราว์เซอร์หลักทั้งหมดได้ลบการสนับสนุนใบรับรอง partial-wildcard ออกไปโดยเจตนา ^{[ 22 ] [ 23 ] ซึ่งจะส่งผลให้เกิดข้อผิดพลาด "SSL_ERROR_BAD_CERT_DOMAIN" ในทำนองเดียวกัน เป็นเรื่องปกติที่ไลบรารีมาตรฐานในภาษาโปรแกรมจะไม่สนับสนุนใบรับรอง "partial-wildcard" ตัวอย่างเช่น ใบรับรอง "partial-wildcard" ใดๆ ก็ตามจะไม่ทำงานกับ Python [ 24 ]} และ Go เวอร์ชันล่าสุดดังนั้น

ไม่อนุญาตให้ใช้ป้ายกำกับที่ประกอบด้วยสัญลักษณ์ตัวแทน (wildcard) ทั้งหมด เว้นแต่จะเป็นป้ายกำกับที่อยู่ทางซ้ายสุด

sub1.*.domain.comไม่อนุญาต

ไม่อนุญาตให้ใช้ใบรับรองที่มีสัญลักษณ์ตัวแทนหลายตัวในชื่อ

*.*.domain.com

*ไม่อนุญาตให้ใช้ ใบรับรองที่มี โดเมนระดับบนสุดรวมอยู่ด้วย

*.com

กว้างเกินไปและไม่ควรอนุญาตให้ใช้

*

ชื่อโดเมนระหว่างประเทศที่เข้ารหัสใน ASCII (A-label) คือป้ายกำกับที่เข้ารหัส ASCIIและขึ้นต้นด้วยxn--. URL ที่มีป้ายกำกับระหว่างประเทศไม่สามารถมีไวด์การ์ดได้^{[ 25 ]}

xn--caf-dma.comเป็นcafé.com

xn--caf-dma*.comไม่ได้รับอนุญาต

Lw*.xn--caf-dma.comอนุญาต

• ใบรับรอง EMV: EMVเป็นวิธีการชำระเงินที่ใช้มาตรฐานทางเทคนิคสำหรับบัตรชำระเงินเครื่องรับชำระเงินและเครื่องเอทีเอ็ม (ATM) บัตรชำระเงิน EMV จะมีใบรับรองผู้ออกบัตรที่ลงนามโดยหน่วยงานออกใบรับรอง EMV ^{[ 26 ]}เพื่อตรวจสอบความถูกต้องของบัตรชำระเงินในระหว่างการทำธุรกรรมการชำระเงิน
• ใบรับรองการลงนามรหัส : ใบรับรองสามารถใช้ตรวจสอบความถูกต้องของแอปพลิ เคชัน (หรือไฟล์ไบนารี ) เพื่อให้แน่ใจว่าไม่มีการแก้ไขดัดแปลงระหว่างการส่งมอบ
• ใบรับรองที่ผ่านการรับรอง : ใบรับรองที่ระบุตัวบุคคล โดยทั่วไปใช้เพื่อ วัตถุประสงค์ ในการลงลายมือชื่ออิเล็กทรอนิกส์ ใบรับรอง ประเภทนี้ใช้กันอย่างแพร่หลายในยุโรป ซึ่ง ระเบียบ eIDASได้กำหนดมาตรฐานและกำหนดให้ต้องยอมรับใบรับรองเหล่านี้
• ใบรับรองตามบทบาท: ใบรับรองตามบทบาทที่กำหนดไว้ใน นโยบายใบรับรอง X.509สำหรับหน่วยงานรับรองสะพานของรัฐบาลกลาง (FBCA)นั้น "ระบุบทบาทเฉพาะที่ผู้สมัครได้รับอนุญาตให้ดำเนินการแทนชื่อของผู้สมัคร และออกให้เพื่อสนับสนุนแนวทางปฏิบัติทางธุรกิจที่ยอมรับ" ^{[ 27 ]}
• ใบรับรองกลุ่ม: กำหนดไว้ใน นโยบายใบรับรอง X.509สำหรับหน่วยงานรับรองสะพานของรัฐบาลกลาง (FBCA)สำหรับ "กรณีที่มีหลายหน่วยงานที่ทำหน้าที่เดียวกัน และไม่ต้องการการปฏิเสธการทำธุรกรรม" ^{[ 28 ]}

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

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

นี่คือตัวอย่างของใบรับรอง SSL/TLS ที่ถอดรหัสแล้ว ซึ่งดึงมาจากเว็บไซต์ SSL.com ชื่อทั่วไป (CN) ของผู้ออกใบรับรองแสดงเป็น < expanded validation> SSL.com EV SSL Intermediate CA RSA R3ซึ่งระบุว่าเป็น ใบรับรอง แบบ Extended Validation (EV) ข้อมูลที่ตรวจสอบแล้วเกี่ยวกับเจ้าของเว็บไซต์ (SSL Corp) อยู่ในSubjectฟิลด์ < input type X509v3 Subject Alternative Name="header"> ฟิลด์ <input type="header"> ประกอบด้วยรายการชื่อโดเมนที่ครอบคลุมโดยใบรับรอง ฟิลด์ <input type="header"> X509v3 Extended Key Usageและ <input type="header"> X509v3 Key Usageแสดงการใช้งานที่เหมาะสมทั้งหมด

ใบรับรอง: ข้อมูล: เวอร์ชัน: 3 (0x2) หมายเลขประจำเครื่อง: 72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31 อัลกอริทึมลายเซ็น: sha256WithRSAEncryption ผู้ออกบัตร: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3 ความถูกต้อง ไม่ก่อนวันที่: 18 เมษายน 2562 เวลา 22:15:06 GMT ไม่ใช่หลังจาก : 17 เม.ย. 2021 22:15:06 GMT เรื่อง: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US ข้อมูลคีย์สาธารณะของหัวเรื่อง: อัลกอริทึมกุญแจสาธารณะ: rsaEncryption คีย์สาธารณะ RSA: (2048 บิต) ค่าสัมบูรณ์: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ... เลขชี้กำลัง: 65537 (0x10001) ส่วนขยาย X509v3: รหัสระบุคีย์อำนาจ X509v3: รหัส:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD การเข้าถึงข้อมูลของหน่วยงาน: ผู้ออกใบรับรอง CA - URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http://ocsps.ssl.com X509v3 ชื่อทางเลือกของหัวเรื่อง: DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com นโยบายใบรับรอง X509v3: นโยบาย: 2.23.140.1.1 นโยบาย: 1.2.616.1.113527.2.5.1.1 นโยบาย: 1.3.6.1.4.1.38064.1.1.1.5 CPS: https://www.ssl.com/repository วิธีใช้งานคีย์เสริม X509v3: การตรวจสอบสิทธิ์ไคลเอ็นต์เว็บ TLS, การตรวจสอบสิทธิ์เซิร์ฟเวอร์เว็บ TLS จุดกระจาย CRL ของ X509v3: ชื่อเต็ม: URI: http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl รหัสระบุหัวข้อ X509v3: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B การใช้งานคีย์ X509v3: สำคัญ ลายเซ็นดิจิทัล, การเข้ารหัสคีย์ หลักสูตรเตรียมสอบใบรับรอง CT SCT: ประทับเวลาบนใบรับรองที่ลงนามแล้ว: เวอร์ชัน : v1 (0x0) รหัสบันทึก : 87:75:BF:E7:59:7C:F8:8C:43:99 ... เวลา: 18 เมษายน 2562 เวลา 22:25:08.574 GMT ส่วนขยาย: ไม่มี ลายเซ็น : ecdsa-with-SHA256 30:44:02:20:40:51:53:90:C6:A2 ... ประทับเวลาบนใบรับรองที่ลงนามแล้ว: เวอร์ชัน : v1 (0x0) Log ID : A4:B9:09:90:B4:18:58:14:87:BB ... เวลา: 18 เมษายน 2562 เวลา 22:25:08.461 GMT ส่วนขยาย: ไม่มี ลายเซ็น : ecdsa-with-SHA256 30:45:02:20:43:80:9E:19:90:FD ... ประทับเวลาบนใบรับรองที่ลงนามแล้ว: เวอร์ชัน : v1 (0x0) รหัสบันทึก : 55:81:D4:C2:16:90:36:01:4A:EA ... เวลา: 18 เมษายน 2562 เวลา 22:25:08.769 GMT ส่วนขยาย: ไม่มี ลายเซ็น : ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40 ... อัลกอริทึมลายเซ็น: sha256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...

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

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

หน่วยงานออกใบรับรองยังมีหน้าที่รับผิดชอบในการรักษาข้อมูลการเพิกถอนใบรับรองที่ออกให้เป็นปัจจุบัน โดยระบุว่าใบรับรองยังคงมีผลใช้ได้หรือไม่ พวกเขาให้ข้อมูลนี้ผ่านโปรโตคอลสถานะใบรับรองออนไลน์ (OCSP) และ/หรือรายการเพิกถอนใบรับรอง (CRL) หน่วยงานออกใบรับรองขนาดใหญ่บางแห่งในตลาด ได้แก่IdenTrust , DigiCertและSectigo ^{[ 29 ]}

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

นโยบายและกระบวนการที่ผู้ให้บริการใช้ในการตัดสินใจว่าซอฟต์แวร์ของตนควรเชื่อถือหน่วยงานออกใบรับรองใด เรียกว่า โปรแกรมหลัก (root programs) โปรแกรมหลักที่มีอิทธิพลมากที่สุด ได้แก่:

• โปรแกรมรูทของ Microsoft
• โปรแกรมรากแอปเปิล
• โปรแกรมรูท Mozilla
• โปรแกรมรูท Oracle Java
• Adobe AATL ( Adobe Approved Trust List) และEUTL (EUTL ) โปรแกรมหลักที่ใช้สำหรับการลงนามเอกสาร

โดยทั่วไปแล้วเบราว์เซอร์อื่นๆ นอกเหนือจาก Firefox จะใช้สิ่งอำนวยความสะดวกของระบบปฏิบัติการในการตัดสินใจว่าหน่วยงานออกใบรับรองใดที่เชื่อถือได้ ตัวอย่างเช่น Chrome บน Windows จะเชื่อถือหน่วยงานออกใบรับรองที่รวมอยู่ใน Microsoft Root Program ในขณะที่บน macOS หรือ iOS Chrome จะเชื่อถือหน่วยงานออกใบรับรองใน Apple Root Program ^{[ 30 ]} Edge และ Safari ก็ใช้ที่เก็บความเชื่อถือของระบบปฏิบัติการของตนเองเช่นกัน แต่แต่ละอันจะใช้งานได้เฉพาะบนระบบปฏิบัติการเดียวเท่านั้น Firefox ใช้ที่เก็บความเชื่อถือของ Mozilla Root Program บนทุกแพลตฟอร์ม

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

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

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

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

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

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

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

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

ผู้ให้บริการใบรับรองจะออกใบรับรองที่ตรวจสอบโดเมน (DV) ให้แก่ผู้ซื้อ หากผู้ซื้อสามารถแสดงให้เห็นถึงเกณฑ์การตรวจสอบข้อใดข้อหนึ่ง ได้แก่ สิทธิ์ในการบริหารจัดการโดเมน DNS ที่เกี่ยวข้อง

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

ในการขอรับ ใบรับรอง Extended Validation (EV) ผู้ซื้อจะต้องโน้มน้าวให้ผู้ให้บริการใบรับรองยืนยันตัวตนทางกฎหมายของตน ซึ่งรวมถึงการตรวจสอบยืนยันด้วยตนเองโดยมนุษย์ เช่นเดียวกับใบรับรอง OV ผู้ให้บริการใบรับรองจะเผยแพร่เกณฑ์การตรวจสอบ EV ผ่านนโยบายใบรับรอง ของ ตน

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

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

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

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

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

แม้จะมีข้อจำกัดดังที่กล่าวมาข้างต้น TLS ที่ตรวจสอบความถูกต้องด้วยใบรับรองยังคงถือเป็นข้อบังคับตามแนวทางด้านความปลอดภัยทั้งหมดเมื่อใดก็ตามที่เว็บไซต์จัดเก็บข้อมูลที่เป็นความลับหรือดำเนินการธุรกรรมสำคัญ ทั้งนี้เพราะในทางปฏิบัติ แม้จะมีจุดอ่อนดังที่กล่าวมาข้างต้น เว็บไซต์ที่ได้รับการรักษาความปลอดภัยด้วยใบรับรองกุญแจสาธารณะก็ยังคงมีความปลอดภัยมากกว่าเว็บไซต์http:// ที่ไม่ปลอดภัย ^{[ 45 ]}

แผนกความปลอดภัยคอมพิวเตอร์ของสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ ( NIST ) ^{[ 46 ]}จัดทำเอกสารคำแนะนำสำหรับใบรับรองกุญแจสาธารณะ:

• SP 800-32 บทนำเกี่ยวกับเทคโนโลยีคีย์สาธารณะและโครงสร้างพื้นฐาน PKI ของรัฐบาลกลาง^{[ 47 ]}
• SP 800-25 หน่วยงานรัฐบาลกลางใช้เทคโนโลยีคีย์สาธารณะสำหรับลายเซ็นดิจิทัลและการตรวจสอบสิทธิ์^{[ 48 ]}

• ใบรับรองการอนุญาต
• ความเป็นส่วนตัวค่อนข้างดี

• ชุง แทจุง; ล็อก เจย์; จันดราเซการัน บาลากฤษณัน; ชอฟฟ์เนส เดวิด; เลวิน เดฟ; แม็กส์ บรูซ เอ็ม.; มิสเลิฟ อลัน; รูลา จอห์น; ซัลลิแวน นิค; วิลสัน คริสโต (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 .