ข้อผิดพลาดความปลอดภัยและการเซ็น

ภาพรวมโดยสรุป

หน้านี้บันทึก exception ในโดเมนความปลอดภัยในต้นไม้ namespace NextPDF\Security แต่ละรายการระบุชื่อคลาส ระบุว่ามันถูกยกเมื่อใด แสดงรายการ ฟิลด์ที่ getContext() ของมันคืน และให้ขั้นตอนการกู้คืน

คลาสเหล่านี้ส่วนใหญ่สืบทอดจาก SecurityException ซึ่งสืบทอดจาก NextPdfException และนำ ContextAwareExceptionInterface ไปใช้ นั่นหมายความว่า getContext(): array คืนการวินิจฉัยแบบมีโครงสร้างที่ปราศจากความลับซึ่งคุณส่งไปยังการล็อกหรือ ไปป์ไลน์ application performance monitoring (APM) ได้ จับ SecurityException เพื่อ ดักความล้มเหลวในโดเมนความปลอดภัยทุกอย่างในบล็อกเดียว จับซับคลาสที่เฉพาะเจาะจงเมื่อ คุณต้องการ payload แบบมีชนิดของมัน

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

แนวปฏิบัติของฟิลด์ context

Aspect	Behavior
Base contract	NextPdfException::getContext() คืน [] ซับคลาสเขียนทับมัน
Secret hygiene	ข้อความและ context ละเว้นวัสดุคีย์ดิบ plaintext PIN และไบต์ initialization vector (IV) คีย์จะถูกเปิดเผยเฉพาะเป็น prefix ของ fingerprint เท่านั้น
SecurityException	ฐาน abstract ไม่พกพาฟิลด์ของตัวเอง ซับคลาสนิยาม payload

ชนิดฐาน

SecurityException

• ถูกยกเมื่อใด ไม่เคยถูกยกโดยตรง มันเป็นฐาน abstract สำหรับโดเมน ความปลอดภัย มันมีอยู่เพื่อให้บล็อก catch (SecurityException $e) เดียวสามารถ ดักความล้มเหลวความครบถ้วนของ authenticated-encryption การป้องกัน nonce-reuse การผูก PDF/A-กับ-การเข้ารหัสลับ ข้อบกพร่องการจัดการคีย์ และความล้มเหลว PKI
• Context fields ไม่มีของตัวเอง สืบทอดค่าเริ่มต้นว่างจาก NextPdfException ซับคลาสเติม payload
• Recovery จับซับคลาสที่เป็นรูปธรรมสำหรับการจัดการที่ทำตามได้ หรือ SecurityException สำหรับการส่งเหตุการณ์ความปลอดภัยแบบหยาบ

ข้อผิดพลาดของการเข้ารหัสลับและการเข้ารหัสลับแบบยืนยันตัวตน

สิ่งเหล่านี้ถูกยกโดย encryptor แบบ AES-GCM (Galois/Counter Mode) และ guard ของ PDF/A สำหรับคำแนะนำที่เริ่มจากอาการ ดู Encryption and permissions

DecryptionFailedException

• ถูกยกเมื่อใด การถอดรหัสแบบ authenticated-encryption with associated data (AEAD) ล้มเหลวด้วยเหตุผลที่ไม่ใช่การแก้ไข: ciphertext ที่ถูกตัดทอน IV ที่ ขาดหายไป หรือคีย์ผิดที่ป้อนที่ขอบเขต API ซึ่งมีวัสดุไม่เพียงพอ ให้การตรวจความครบถ้วนทำงานได้จริง นี่เป็นข้อผิดพลาดด้านการกำหนดค่าหรือ การขนส่ง ไม่ใช่เหตุการณ์ความปลอดภัย
• Context fields algorithm (ตัวอย่างเช่น AES-256-GCM), reason (ตัวอย่าง เช่น ciphertext shorter than IV+tag)
• Recovery ตรวจสอบว่า ciphertext, IV, และคีย์ครบถ้วนและถูกวางกรอบ อย่างถูกต้อง อย่าถือว่านี่เป็นการแก้ไข เปรียบเทียบกับ TamperedDataException

TamperedDataException

• ถูกยกเมื่อใด authentication tag ของ AEAD ตรวจสอบยืนยันไม่ผ่าน tag ครอบคลุม ciphertext บวก associated authenticated data (AAD) หากด้านใดถูกแก้ไข หลังการเข้ารหัสลับ openssl_decrypt() พื้นฐานจะคืน false ซับชนิด ที่ต่างกันนี้ทำให้คุณปรากฏการเตือนระดับเหตุการณ์ความปลอดภัยแทนข้อผิดพลาด การวางกรอบ
• Context fields algorithm, ciphertext_length (ความยาวของ ciphertext ที่ ถูกปฏิเสธ ไม่รวม IV และ tag)
• Recovery ถือว่าเป็นการแก้ไขหรือคีย์/IV ผิด อย่าลองใหม่แบบมืดบอด ตรวจสอบแหล่งที่มาของ ciphertext ตาม ISO/TS 32003:2023 §5.2 และ NIST SP 800-38D §6.5 การตรวจ tag ที่ล้มเหลวหมายถึงข้อมูลไม่เป็นของแท้

NonceReuseException

• ถูกยกเมื่อใด AES-GCM ถูกขอให้เข้ารหัสลับสองครั้งด้วยคู่คีย์และ IV เดียวกัน encryptor ป้องกันด้วยตัวนับ monotonic ต่ออินสแตนซ์ และเป็น defense in depth ด้วย hash-set ขณะรันไทม์ของทุกคู่ (key-fingerprint, IV) ที่ปล่อยออกมา เนื่องจากตัวนับตัดความเป็นไปได้ของการชนกันโดยการก่อสร้าง การยิงนี้ จึงเป็นตัวบ่งชี้บั๊กระดับสำคัญที่ต้องไม่เกิดในการใช้งานจริง การใช้ซ้ำ คู่คีย์/IV ทำลาย keystream ทั้งหมด (ISO/TS 32003:2023 §5.2 NOTE 2; NIST SP 800-38D §8.3)
• Context fields key_fingerprint_prefix (8 อักขระ hex แรกของ SHA-256(key)), iv_length (เป็น 12 เสมอสำหรับ ISO/TS 32003), reason (hashset-collision หรือ counter-rollover แยกบั๊กการ refactor ที่ทำลาย ตัวนับออกจาก trip-wire ตัวนับ 2^63) และ iv_fixed_field_hex (ฟิลด์ fixed ของ IV ปรากฏเฉพาะเมื่อมีการป้อน รายงานภายใต้คีย์ของตัวเองและไม่เคย ติดป้ายผิดเป็น fingerprint ของคีย์)
• Recovery ยกเลิกทันทีและหมุนคีย์ ยื่นรายงานข้อบกพร่อง นี่ บ่งชี้บั๊กใน encryptor ไม่ใช่ input ของผู้เรียกที่ไม่ดี

GcmInvocationLimitExceededException

• ถูกยกเมื่อใด จำนวนการเรียกใช้แบบ opt-in ที่ปลอดภัยต่อการใช้ตาม NIST SP 800-38D §8.3 ถึงเกณฑ์สำหรับคีย์ AES-GCM ที่กำหนด นี่เป็น hook telemetry แบบ defense-in-depth สำหรับผู้เรียกที่ต้องการบังคับใช้ขอบเขตที่สเปกแนะนำ (ราว 2^32 การเรียกใช้ต่อคีย์) เร็วกว่าขีดจำกัดเชิงสถาปัตยกรรมภายใน encryptor มันไม่ยิงโดยค่าเริ่มต้น เฉพาะ helper assertWithinSafetyBound() เท่านั้นที่ยกมัน
• Context fields key_fingerprint_prefix, invocation_count (จำนวน encrypt() ปัจจุบัน ที่หรือเหนือขีดจำกัด), invocation_limit (ขอบเขตแบบ opt-in)
• Recovery หมุนคีย์เอกสาร (สร้าง encryptor ใหม่ด้วยวัสดุคีย์ใหม่) ก่อนที่ความน่าจะเป็นสะสมของการชนกันและการปลอมแปลงจะหยุดเป็น สิ่งเล็กน้อย หรือขยายนโยบายผู้เรียกให้ปฏิเสธการให้บริการต่อ

IncompatiblePdfAModeException

• ถูกยกเมื่อใด มีการพยายาม operation การเข้ารหัสลับบนเอกสารที่แท็ก PDF/A ตระกูล PDF/A (PDF/A-2, PDF/A-3, PDF/A-4) ห้ามการเข้ารหัสลับ อย่างสม่ำเสมอ: ตาม ISO 19005 §6.1.3 คีย์ Encrypt ต้องไม่ปรากฏใน trailer และ ISO 19005-4:2020 Annex A และ B สืบทอดสิ่งนี้โดยไม่ ดัดแปลง ไม่มีการรวมกันของ PDF/A และการเข้ารหัสลับที่อนุญาต
• Context fields pdfa_mode (ตัวอย่างเช่น pdfa4, pdfa3), encryption_operation (การเรียกที่ถูกปฏิเสธ ตัวอย่างเช่น useAesGcm)
• Recovery หากต้องการสร้างเอกสารที่เข้ารหัสลับ ให้ละการเรียก enablePdfA() หากต้องการ สร้างเอกสาร archival ให้ละการเรียกการเข้ารหัสลับ ดู PDF/A and PDF/UA validation

การบังคับใช้นโยบายการเข้ารหัสลับ

CryptoPolicyViolationException

• ถูกยกเมื่อใด นโยบาย crypto ที่กำหนดค่าไว้ปฏิเสธอัลกอริทึม ความแข็งแกร่งของคีย์ หรือ cipher ที่ operation การเซ็น การเข้ารหัสลับ หรือการแฮชของ core เลือก มันเป็น ขอบเขตล้มเหลวแบบปิดสำหรับการบังคับใช้ compliance (ตัวอย่างเช่น FIPS 140-2/3 eIDAS หรือนโยบายองค์กรแบบกำหนดเอง) และถูกยกโดย CryptoPolicyEnforcer ก่อนการสร้างลายเซ็นหรือ ciphertext ใดๆ operation ที่ละเมิดนโยบาย จึงไม่อาจปล่อย artifact ที่ไม่ได้รับอนุมัติได้เลย แตกต่างจากความล้มเหลวของ operation OpenSSL แบบแคบและจากความล้มเหลวของ signing-primitive: นี่คือการปฏิเสธเชิงนโยบาย ต่อคำขอที่ถูกต้องโดยอื่น สอดคล้องกับ NIST SP 800-131A Rev. 2 และ ISO/IEC 19790:2025 §7
• Context fields policy (ชื่อนโยบาย ตัวอย่างเช่น FIPS 140-3 Strict), category (hash, signature, encryption, หรือ key-strength), item (รายการ ที่ถูกปฏิเสธ ตัวอย่างเช่น object identifier (OID) ชื่อ cipher หรือ rsa/1024), reason
• Recovery เลือกอัลกอริทึม ความยาวคีย์ หรือ cipher ที่นโยบายที่ระบุชื่อ อนุมัติ หรือปรับนโยบายหากคุณเป็นเจ้าของ ส่ง context แบบมีโครงสร้างไปยัง runbook compliance ที่บันทึกไว้

การจัดการคีย์

มีคลาสที่ชื่อเหมือนกันสองตัว มันใช้ราก SecurityException ร่วมกันเพื่อให้บล็อก catch (SecurityException $e) เดียวดักทั้งสอง แต่มันพกพา payload ที่แตกต่างกัน นำเข้าด้วยชื่อที่ระบุครบถ้วนเมื่อคุณต้องการรูปทรงที่เฉพาะเจาะจง

KeyManagementException (วงจรชีวิต: NextPDF\Security\Exception)

• ถูกยกเมื่อใด operation การจัดการคีย์ล้มเหลวก่อนที่คีย์จะถูกใช้โดย primitive การเซ็นหรือเข้ารหัสลับ: ความล้มเหลวการแยกวิเคราะห์คีย์ Privacy-Enhanced Mail (PEM), PKCS#12 หรือ PKCS#11 ความล้มเหลวการ derive คีย์ (HKDF, PBKDF2, scrypt) การปฏิเสธ AES Key Wrap (RFC 3394) บน key-encryption key ที่ผิด hardware security module (HSM) คืน Distinguished Encoding Rules (DER) ที่มีรูปแบบไม่ถูกต้อง หรือความยาว seed Ed25519 ไม่ตรงกัน
• Context fields operation (ตัวอย่างเช่น load_pem, kek_derive, key_wrap), key_type (ตัวอย่างเช่น RSA, EC-P256, Ed25519, AES-256), reason วัสดุคีย์ดิบไม่เคยถูกรวมไว้
• Recovery ตรวจสอบ operation และชนิดคีย์ที่ระบุชื่อ แก้วัสดุคีย์ต้นทาง หรือ input การ derive แล้วลองใหม่

KeyManagementException (เส้นทางการลงนาม: NextPDF\Security\Signature\Exception)

• ถูกยกเมื่อใด signer provider พบข้อบกพร่องการจัดการคีย์: เวอร์ชันคีย์ที่ ร้องขอไม่รู้จัก ถูกปิดใช้งาน กำหนดให้ทำลาย ขาดสิทธิ์การเซ็น หรือใช้ไม่ได้โดยอื่น นี่คือสิ่งที่ RsaPssSigner และ LocalKeySignerProvider ยกขึ้นเมื่อคีย์ที่ใช้งานล้มเหลว constructor ที่ระบุชื่อ: unknownKeyVersion() และ keyVersionDisabled()
• Context fields providerId, keyVersion, reason accessor: providerId(), keyVersion(), reason()
• Recovery หมุนหรือให้สิทธิ์คีย์ใหม่ หรือเลือกเวอร์ชันคีย์ที่ใช้ได้ แล้วลองใหม่ แตกต่างจาก SignatureFailedException ซึ่งสื่อว่า signing primitive เองล้มเหลว

การลงนาม

สำหรับคำแนะนำที่เริ่มจากอาการเกี่ยวกับระดับที่เข้าถึงไม่ได้และความสามารถที่ขาดหาย ดู Signature and timestamp failures

SignatureFailedException (R4-13: NextPDF\Security\Exception)

• ถูกยกเมื่อใด operation การเซ็นเชิงการเข้ารหัสลับล้มเหลว: primitive การเซ็น RSA, ECDSA หรือ Ed25519 คืน false หรือเอาต์พุตความยาวผิด HSM หรือ token PKCS#11 ตอบด้วยสถานะที่ไม่สำเร็จ การประกอบ Cryptographic Message Syntax (CMS) SignedData ล้มเหลวบนใบรับรองหรือห่วงโซ่ที่มีรูปแบบไม่ถูกต้อง หรือ Ed25519 round-trip self-verify ล้มเหลว โค้ดใหม่ควรเลือกซับชนิด R4-13 นี้แทน signature exception แบบ PAdES-coupled เดิม
• Context fields operation (ตัวอย่างเช่น sign, verify, build_cms), algorithm (ตัวอย่างเช่น rsa-pkcs1v15-sha256, ed25519), reason accessor: getOperation(), getAlgorithm(), getReason()
• Recovery อ่าน operation และอัลกอริทึม แก้ input (คีย์ ห่วงโซ่ใบรับรอง หรือความพร้อมของ backend) แล้วลองใหม่ สอดคล้องกับ ท่าทีการจัดการคีย์แบบล้มเหลวแบบปิดของ ETSI EN 319 142-1

SignatureFailedException (SPI: NextPDF\Security\Signature\Exception)

• ถูกยกเมื่อใด การนำ SignerProviderInterface ไปใช้ไม่อาจทำ operation การเซ็นให้สำเร็จด้วยเหตุผลใดๆ ที่ไม่จัดเป็นการจัดการคีย์: ข้อผิดพลาด ของ driver backend วัสดุคีย์ที่มีรูปแบบไม่ถูกต้อง หรือ HSM I/O ที่กู้คืนไม่ได้ นี่คือ catch-all สำหรับสัญญาการเซ็นแบบล้มเหลวแบบปิด ซึ่งทุก primitive ยกเมื่อ ล้มเหลวแทนการคืน null, false, หรือ string ว่าง constructor ที่ระบุชื่อ: forProvider()
• Context fields providerId, reason accessor: providerId(), reason()
• Recovery ตรวจสอบ provider id และเหตุผล แก้ backend ของ provider หรือ วัสดุคีย์ แล้วลองใหม่ แยกกิ่งระหว่าง KeyManagementException กับชนิดนี้เพื่อ แยก “คีย์ไม่ดี” ออกจาก “primitive ล้มเหลว”

SignatureLevelUnreachableException

• ถูกยกเมื่อใด ระดับความสอดคล้อง PAdES ที่ร้องขอไม่อาจสนองได้ภายใต้ โครงสร้างพื้นฐานรันไทม์ปัจจุบัน (ส่วนใหญ่คือผู้ออกใบรับรองการประทับเวลาที่ขาดหายสำหรับ B-T ขึ้นไป) และผู้เรียกไม่ได้อนุญาตให้ลดทอน ค่าเริ่มต้น คือล้มเหลวแบบปิด: เอนจินปฏิเสธแทนการสร้างระดับที่ต่ำกว่าอย่างเงียบๆ ขณะประกาศระดับที่สูงกว่า ซึ่งจะเป็นการถดถอยระดับ eIDAS สอดคล้องกับ ETSI EN 319 142-1 §6 โปรดทราบว่าคลาสนี้สืบทอดจาก NextPdfException โดยตรง (ไม่ใช่ SecurityException)
• Context fields requestedLevel, highestAchievableLevel, reason accessor: requestedLevel(), highestAchievableLevel(), reason()
• Recovery อ่าน reason เพื่อระบุโครงสร้างพื้นฐานที่ขาดหายและจัดหา มัน (ตัวอย่างเช่น กำหนดค่าผู้ออกใบรับรองการประทับเวลา) หรือส่ง allowDegradation: true ไปยัง PadesOrchestrator เพื่อยอมรับระดับที่สร้างได้สูงสุดโดยเจตนา

SignerProviderNotFoundException

• ถูกยกเมื่อใด SignerProviderRegistry::get() ถูกขอ provider id ที่ ไม่ได้ลงทะเบียน นำ PSR-11 NotFoundExceptionInterface ไปใช้ registry จึง สอดคล้องกับสัญญาคอนเทนเนอร์ PSR-11 constructor ที่ระบุชื่อ: forId() คลาสนี้สืบทอดจาก RuntimeException และไม่เปิดเผย getContext()
• Context fields ไม่มี id ที่ไม่ได้ลงทะเบียนปรากฏในข้อความ
• Recovery ลงทะเบียน provider ภายใต้ id ที่คาดหวังก่อนร้องขอ หรือแก้ id ที่คุณส่งไปยัง registry

การแฮช (SHAKE256)

สิ่งเหล่านี้สืบทอดจาก RuntimeException และไม่เปิดเผย getContext() SHAKE256 เป็น extendable-output function ของ SHA-3 ที่บางเส้นทางของ ISO/TS 32001 ต้องการ

Shake256NotAvailableException

• ถูกยกเมื่อใด ที่เวลา digest เมื่อ provider ที่เลือกไม่อาจสนอง คำขอได้ constructor ที่ระบุชื่อ: noBackend() (ไม่มี backend SHAKE256 ที่ทำงานบน host นี้ ในทุก tier ที่พยายาม) และ ffiCallFailed() (การเรียก OpenSSL EVP ที่ผูกผ่าน FFI คืนสถานะที่ไม่สำเร็จ ตัวอย่างเช่นจากบิลด์ libcrypto ที่ถูก strip)
• Context fields ไม่มี ข้อความระบุชื่อ tier ที่พยายามหรือ symbol ที่ล้มเหลว
• Recovery ติดตั้ง ext-ffi พร้อม OpenSSL 3.x หรืออัปเกรดเป็นบิลด์ PHP ที่เปิดเผย shake256 ใน hash_algos() fallback Keccak ใน userland ถูก ละเว้นโดยเจตนา

Shake256ProviderNotAvailableException

• ถูกยกเมื่อใด จาก constructor ของ provider SHAKE256 เมื่อการตรวจความสามารถ ล้มเหลว provider จึงไม่อาจสร้างอินสแตนซ์ได้ มันเป็นสัญญาณ control-flow: registry ของ provider จับมัน บันทึกป้าย tier และลอง tier ถัดไป มันไม่ควรหลุดเข้าสู่โค้ดแอปพลิเคชัน constructor ที่ระบุชื่อ: forTier()
• Context fields ไม่มี ข้อความระบุชื่อ tier และเหตุผล
• Recovery ไม่ใช่สิ่งที่ผู้เรียกทำตามได้โดยตรง หากห่วงโซ่ tier ทั้งหมด หมดลง registry จะปรากฏ Shake256NotAvailableException::noBackend() แทน ซึ่งพกพาการแก้ไขที่ผู้ปฏิบัติงานเห็น

ความสมบูรณ์ของ Document MAC (ISO/TS 32004)

สิ่งเหล่านี้ครอบคลุม message authentication code (MAC) ระดับเอกสารตาม ISO/TS 32004 ที่เก็บไว้ภายใต้ /AuthCode ทั้งสองสืบทอดจาก NextPdfException และเขียนทับ getContext()

DocumentMacTokenException

• ถูกยกเมื่อใด ล้มเหลวแบบปิด โดยตัวอ่าน MAC token เมื่อ CMS AuthenticatedData MAC token มีโครงสร้างผิดรูปหรือประกาศอัลกอริทึม นอกชุด ISO/TS 32004 ที่ตกลงกัน constructor ที่ระบุชื่อ: malformed() และ algorithmMismatch() ทำเครื่องหมาย @internal
• Context fields status (ค่า DocumentMacVerificationStatus ไม่ว่าจะ MalformedToken หรือ AlgorithmMismatch) พร็อพเพอร์ตี public readonly: $status
• Recovery ถือว่าเอกสารยังไม่ได้รับการตรวจสอบยืนยัน token ที่ผิดรูปหรือ อัลกอริทึมนอกชุดที่ตกลงกันหมายความว่า MAC ไม่อาจสร้างความเชื่อถือได้ อย่า ดำเนินการต่อราวกับว่าเนื้อหาถูกปกป้อง

DocumentMacVerificationException

• ถูกยกเมื่อใด ล้มเหลวแบบปิด เมื่อการตรวจสอบ MAC ระดับเอกสารไม่อาจไปถึง สถานะที่เชื่อถือได้: /AuthCode ที่ขาดหายหรือผิดรูป อัลกอริทึมนอก ชุดที่ตกลงกัน ความล้มเหลวการ unwrap หรือ MAC ไม่ตรงกัน (tamper) verify() ของ verifier คืนผลลัพธ์ที่ชัดเจนสำหรับการแยกกิ่ง นี่คือคู่ exception-flow ที่ยกโดย assertVerified() เพื่อให้โค้ด “เชื่อเนื้อหา” ไม่อาจ ดำเนินผ่านเอกสารที่ยังไม่ได้รับการตรวจสอบยืนยันได้ constructor ที่ระบุชื่อ: fromResult()
• Context fields status (ค่า DocumentMacVerificationStatus) พร็อพเพอร์ตี public readonly: $status
• Recovery อย่าเชื่อเนื้อหาเอกสาร ตรวจสอบ status เพื่อแยก tamper (MAC ไม่ตรงกัน) ออกจากปัญหาการกำหนดค่า (/AuthCode ที่ขาดหายหรือผิดรูป หรืออัลกอริทึมไม่ตรงกัน)

การตรวจสอบเส้นทาง PKI (RFC 5280)

สิ่งเหล่านี้ครอบคลุมการตรวจสอบ certification-path ตาม RFC 5280 ชนิดฐานและซับ คลาสของมันล้มเหลวแบบปิด

PkiPathValidationException

• ถูกยกเมื่อใด ความล้มเหลวในโหมด strict จาก path validator ของ RFC 5280 มันเป็น ฐานที่ไม่ใช่ final สำหรับซับคลาสที่แคบกว่า (ChainLengthExceededException, UnsupportedExtensionException) ดังนั้นตัวจัดการที่จับชนิดนี้ก็จับ ชนิดเหล่านั้นด้วยผ่าน Liskov substitution สืบทอดจาก SecurityException
• Context fields ไม่เขียนทับ getContext() (สืบทอดค่าเริ่มต้นว่าง) พกพาเหตุผลแบบมีโครงสร้างในพร็อพเพอร์ตี public readonly array ที่ frozen $reasons (รายการที่ไม่ว่างของชื่อกฎบวก string คำอธิบาย)
• Recovery อ่าน $reasons เพื่อระบุกฎที่ล้มเหลว แก้ห่วงโซ่ใบรับรอง แล้วตรวจสอบยืนยันใหม่ จับชนิดนี้เพื่อจัดการความล้มเหลวการตรวจสอบเส้นทางใดๆ อย่างสม่ำเสมอ

ChainLengthExceededException

• ถูกยกเมื่อใด path validator ถูกขอให้เดินห่วงโซ่ที่มีความยาว เกินเพดานที่กำหนดค่าไว้ เพดานถูกบังคับใช้ก่อนการแยกวิเคราะห์ใดๆ จะเริ่ม ผู้จัดหาที่เป็นอันตรายจึงไม่อาจขับ validator เข้าสู่งานแบบกำลังสองหรือ ทำให้ทรัพยากรหมดด้วยห่วงโซ่ที่ลึกอย่างไร้ขอบเขต เพดานเริ่มต้นที่ 10 ตามโปรไฟล์ PKIX-CMP (RFC 4210 §5.3.18) ห่วงโซ่ในโลกจริงพอดีใน 5 ถึง 6 รายการ ซับคลาสของ PkiPathValidationException
• Context fields สืบทอด getContext() ว่าง string เหตุผล chain_length_exceeded: supplied=<n> cap=<n> ถูกส่งต่อเข้าสู่ $reasons ของแม่ พร็อพเพอร์ตี public readonly: $supplied, $cap
• Recovery จัดหาห่วงโซ่ภายในเพดาน หรือเพิ่ม cap ที่กำหนดค่าไว้หาก คาดหวังห่วงโซ่ที่ยาวกว่าโดยชอบธรรม

UnsupportedExtensionException

• ถูกยกเมื่อใด path validator พบ critical X.509 extension ที่ การบังคับใช้ยังไม่ได้ถูกนำไปใช้ ตาม RFC 5280 §4.2 critical extension ที่ไม่รู้จัก ต้องล้มเหลวแบบปิด ทั้งโหมด strict และ lenient ล้มเหลวแบบปิดที่นี่ เพราะ การข้าม critical extension อย่างเงียบๆ จะเป็นการถดถอยด้านความปลอดภัย validator ครอบคลุมการสร้างห่วงโซ่ การจับคู่ AKI/SKI key usage extended key usage basic constraints การหมดอายุ และการตรวจสอบยืนยันลายเซ็น อย่างอื่นที่เป็น critical จะปรากฏที่นี่ ซับคลาสของ PkiPathValidationException
• Context fields สืบทอด getContext() ว่าง เหตุผลแบบมีโครงสร้างถูก ส่งต่อเข้าสู่ $reasons ของแม่ พร็อพเพอร์ตี public readonly: $extensionOid (OID แบบจุด ตัวอย่างเช่น 2.5.29.30 สำหรับ name constraints), $extensionName, $clauseRef (ตัวชี้ไปยัง clause ของ RFC 5280 และรายการ log ของ deferred-items)
• Recovery ในโหมด lenient ให้จับซับคลาสที่เฉพาะเจาะจงนี้เพื่อ fall back ไปยัง นโยบายที่หยาบกว่าโดยไม่กลืนความล้มเหลวการตรวจสอบเส้นทางจริง ตรวจสอบ $extensionOid และ $clauseRef เทียบกับ fixture PKI ของคุณเพื่อดูว่า extension ใด ขัดขวางการตรวจสอบยืนยัน

RevocationCheckFailedException

• ถูกยกเมื่อใด ทั้งปลายทาง OCSP และ certificate revocation list (CRL) ถูกใช้ จนหมดโดยไม่มีคำตัดสินที่ชัดเจน: ความล้มเหลวการขนส่ง OCSP หรือการตอบกลับที่ผิดรูป และความล้มเหลวการขนส่ง CRL หรือ CRL ที่ผิดรูป โดยทั้งสอง circuit breaker เปิดอยู่หรือทั้งสอง cache ขาดหาย โหมด strict ถือว่านี่เป็นล้มเหลวแบบปิด โหมด lenient จับมันและปล่อยคำเตือน PSR-3 พร้อม revocation = null สืบทอดจาก SecurityException
• Context fields ไม่เขียนทับ getContext() (สืบทอดค่าเริ่มต้นว่าง) พกพาสถานะในพร็อพเพอร์ตี public readonly $ocspState และ $crlState (แต่ละตัวเริ่มต้นเป็น unknown)
• Recovery กู้คืนการเข้าถึงแหล่งเพิกถอน รอให้ circuit breaker ปิด หรืออุ่น cache แล้วลองใหม่ อย่าระงับสิ่งนี้เพื่อให้ได้ artifact long-term-validation การยืนยันการเพิกถอนเป็นส่วนหนึ่งของระดับนั้น

การตรวจสอบลายเซ็น OCSP (RFC 6960)

OcspSignatureInvalidException

• ถูกยกเมื่อใด ลายเซ็น BasicOCSPResponse ตาม RFC 6960 §4.2.2.2 ล้มเหลว การตรวจสอบยืนยันเชิงการเข้ารหัสลับเทียบกับใบรับรองของ responder parser ถอดรหัส signatureAlgorithm (RSA-PSS, ECDSA, หรือ RSA-PKCS1v15) และตรวจสอบยืนยัน signature เหนือ tbsResponseData ความล้มเหลวใดๆ ยก exception แบบมีชนิดนี้เพื่อให้ ผู้เรียกแยกการตอบกลับที่มีโครงสร้างถูกต้องแต่ถูกแก้ไขเชิงการเข้ารหัสลับ ออกจากการตอบกลับ DER ที่ผิดรูป ไม่ใช่ final แพ็กเกจปลายน้ำจึงสามารถ เผยแพร่ซับคลาสที่เฉพาะเจาะจงกว่าได้ สืบทอดจาก SecurityException
• Context fields ไม่เขียนทับ getContext() (สืบทอดค่าเริ่มต้นว่าง) พกพา tag ความล้มเหลวในพร็อพเพอร์ตี public readonly $reason (ตัวอย่าง เช่น signature_mismatch, responder_cert_not_in_bundle, unsupported_signature_algorithm) detail แบบ free-text ถูกพับเข้าใน ข้อความ
• Recovery ตรวจสอบ $reason สำหรับ responder_cert_not_in_bundle ให้จัดหา bundle trust anchor ที่ถูกต้องและใบรับรอง responder สำหรับ signature_mismatch ให้ถือว่าการตอบกลับไม่น่าเชื่อถือ ดู Signature and timestamp failures

การประทับเวลา (RFC 3161)

TsaException

• ถูกยกเมื่อใด ความล้มเหลวในการสื่อสารหรือการแยกวิเคราะห์การตอบกลับของ time-stamp authority (TSA) ตาม RFC 3161: TSA คืนสถานะข้อผิดพลาด คำขอ HTTP ล้มเหลว หรือ การตอบกลับ ASN.1 ไม่อาจแยกวิเคราะห์ได้ มันเป็นฐานของลำดับชั้นข้อบกพร่อง TSA และไม่ใช่ final เพื่อให้ความล้มเหลวการตรวจสอบยืนยันสืบทอดได้ สืบทอดจาก NextPdfException
• Context fields ไม่เขียนทับ getContext() (สืบทอดค่าเริ่มต้นว่าง)
• Recovery จับ TsaException สำหรับเส้นทางข้อบกพร่อง TSA ใดๆ ตรวจสอบการ เข้าถึง TSA และว่าปลายทางคืนการตอบกลับ RFC 3161 ที่มีรูปแบบดี

TsaTokenVerificationException

• ถูกยกเมื่อใด การตรวจสอบยืนยัน CMS ของ TimeStampToken ตาม RFC 3161 ล้มเหลวที่ขั้นใด ของขั้นตอนการตรวจสอบยืนยันที่กำหนด: การผูก RFC 5816 §3 ESSCertIDv2 ความครบถ้วน RFC 5652 §11 ของ signed-attributes ความสดของ RFC 3161 §2.4.2 producedAt หรือ ลายเซ็น RFC 5652 §5.4 SignerInfo ล้มเหลวแบบปิด พร้อมตัวแยกแยะขั้นแบบมีชนิด เพื่อให้ไปป์ไลน์ audit แยก replay จาก clock skew จาก cert-mismatch ได้โดยไม่ต้อง grep ข้อความ ซับคลาสของ TsaException ดังนั้นตัวจัดการ catch (TsaException) เดิมยังคงทำงาน
• Context fields step (ค่า Step ของไปป์ไลน์ที่ล้มเหลว) และ message accessor: getStep()
• Recovery ทำตามได้โดยนักพัฒนา (ใบรับรอง TSA ที่กำหนดค่าผิดหรือความ ทนทานต่อ skew) หรือฝ่ายความปลอดภัย (สงสัย MITM หรือ replay) อ่าน step เพื่อระบุ ขั้นที่ล้มเหลวและแก้ input หรือการกำหนดค่าความเชื่อถือที่ตรงกัน

MalformedDerException

• ถูกยกเมื่อใด สัญญาณภายในว่าการเดิน DER ชนขอบเขตที่ผิดรูปหรือถูก ตัดทอน ยกโดย walker ระดับล่างภายในตัวตรวจสอบยืนยัน TSA token มัน ถูกจับที่ขอบเขต verify สาธารณะเสมอและถูก re-wrap เป็น TsaTokenVerificationException ที่พกพาตัวแยกแยะขั้นที่ถูกต้อง มันไม่เคย รั่วไปยังโค้ดผู้เรียก สืบทอดจาก RuntimeException ทำเครื่องหมาย @internal
• Context fields ไม่มี
• Recovery ไม่หันสู่ผู้เรียก จัดการ TsaTokenVerificationException ที่ถูก wrap แทน

การถอดรหัสส่วนขยายใบรับรอง

สิ่งเหล่านี้สืบทอดจาก RuntimeException และไม่เปิดเผย getContext() ทั้งสองเป็น decoder แบบล้มเหลวแบบปิด

NameConstraintsDecodeException

• ถูกยกเมื่อใด decoder ของ name-constraints พบเอลิเมนต์ GeneralSubtree ที่บังคับใช้ได้ซึ่งมันไม่อาจถอดรหัสได้อย่างซื่อตรง RFC 5280 §4.2.1.10 กำหนดให้ relying party ประมวลผล name constraint ที่บังคับใช้ได้หรือปฏิเสธ ใบรับรอง การแปลงการ drop เงียบๆ เดิมเป็นความล้มเหลวแบบมีชนิดนี้ป้องกัน fail-open ที่จะขยายชุดชื่อที่ยอมรับอย่างเงียบๆ ขอบเขตถูก จำกัดไว้ที่รูปแบบชื่อที่บังคับใช้ได้ (directoryName, dNSName, iPAddress, rfc822Name, uniformResourceIdentifier) รูปแบบที่บังคับใช้ไม่ได้ยังคงละเว้น ได้และไม่เคยยกมัน constructor ที่ระบุชื่อ: undecodableEnforceableBase() ทำเครื่องหมาย @internal
• Context fields ไม่มี string รายละเอียดที่ปลอดภัยต่อการล็อกถูกพกพาในข้อความ
• Recovery ตัวบังคับใช้จะปรากฏเหตุผลล้มเหลวแบบปิด name_constraints: และ ห่วงโซ่ถูกปฏิเสธ ตรวจสอบการ encode name-constraints ของใบรับรอง อย่าผ่อนการบังคับใช้

QcStatementsDecodeException

• ถูกยกเมื่อใด extension qcStatements มีโครงสร้างผิดรูป: DER ที่ถูกตัดทอน tag ที่ผิด หรือความยาวล้น decoder ล้มเหลวแบบปิดและ ยกขึ้นแทนการคืนผลลัพธ์บางส่วนหรือแบบ heuristic เมื่อมันไม่อาจ ระบุได้อย่างแน่นอนว่า extension บอกอะไร ทำเครื่องหมาย @api
• Context fields ไม่มี
• Recovery จับมันอย่างชัดเจนเฉพาะเมื่อคุณตั้งใจจะทนต่อการ encode ที่ผิดรูป มิฉะนั้นให้ถือว่า qualified-certificate statement ของใบรับรองเป็นสิ่งที่ ระบุไม่ได้ และปฏิเสธหรือออกใบรับรองใหม่

เซสชัน PKCS#11

Pkcs11SessionException

• ถูกยกเมื่อใด ข้อบกพร่องการจัดการเซสชัน PKCS#11 v3.1 constructor ที่ระบุชื่อ ทุกตัว map ไปยังคลาสข้อบกพร่องที่เฉพาะเจาะจงและไปยังค่าคืน PKCS#11 CKR_* ที่เปิดเผยผ่านตัวแยกแยะ $kind แบบมีชนิดเพื่อให้ผู้เรียกแยกกิ่งบน enum-string ที่เสถียรแทนการจับคู่ข้อความที่เปราะบาง constructor รวมถึง: cryptokiNotInitialized(), userNotLoggedIn(), userAlreadyLoggedIn(), operationNotInitialized(), operationActive(), mechanismNotAllowed(), tokenDisconnected(), concurrentSessionLimitExceeded(), sessionAlreadyClosed(), stateTransitionInvalid(), osLockingRequired(), loginTtlExpired(), และ signOperationTtlExpired() สืบทอดจาก SecurityException
• Context fields ไม่เขียนทับ getContext() (สืบทอดค่าเริ่มต้นว่าง) พกพา kind แบบมีชนิดในพร็อพเพอร์ตี public readonly $kind หนึ่งใน ค่าคงที่ KIND_* (ตัวอย่างเช่น KIND_USER_NOT_LOGGED_IN, KIND_TOKEN_DISCONNECTED, KIND_LOGIN_TTL_EXPIRED) ตัวระบุ slot และ session mechanism และค่า TTL ปรากฏในข้อความ PIN และ ไบต์ใบรับรองไม่เคยถูกรวมไว้
• Recovery switch บน $kind สำหรับ user_not_logged_in ให้ล็อกอินด้วย user PIN ก่อนเริ่ม operation การเซ็น สำหรับ token_disconnected ให้ถือว่าทุก เซสชันบน slot เป็น orphan สำหรับ kind ของ TTL ให้ authenticate ใหม่หรือ re-initialize operation สำหรับ mechanism_not_allowed ให้ขยาย allow-list ของ mechanism ที่กำหนดค่าไว้หรือเลือก mechanism ที่อนุญาต

ดูเพิ่มเติม

• Error reference index
• Signature and timestamp failures
• Encryption and permissions
• PDF/A and PDF/UA validation