شهادة ذاتية التوقيع أم موثوقة؟
السلامة التشفيرية مقابل ثقة الهوية: شهادات ذاتية التوقيع، سلسلة PKI، التحقق من PDF واعتبارات الأمن.
نُشر في 9 سبتمبر 2026 · حُدّث في 3 أكتوبر 2026 · 3 دقيقة قراءة
فهم تحذير القارئ
افتح خصائص التوقيع لفحص الشهادة وسلامة المستند. عدم الثقة بالمُصدر وتعديل المستند نتيجتان مختلفتان. لا تعطّل فحوص الأمان لإخفاء التحذير. هذا التحذير متوقع في العرض التجريبي. جرّب العرض التجريبي
TL;DR
- توقيع PAdES يثبت سلامة PDF (البايتات لم تُغيَّر) ويربط البصمة بمفتاح خاص.
- شهادة X.509 تحمل المفتاح العام وهوية معلنة. ذاتية التوقيع ≠ غير آمنة تشفيرياً؛ تعني غياب سلسلة ثقة عامة.
- العرض التجريبي وsandbox في Khatm: شهادة اختبار ذاتية التوقيع. الإنتاج: PKI / HSM / مزود المشروع. Khatm ليس مزود ثقة مؤهلاً.
خاصيتان منفصلتان تختلطان عند التحقق: (1) هل تغيّر المستند بعد التوقيع؟ (2) هل الهوية المعروضة مثبتة في سلطة ثقة يعرفها المُتحقق؟
نموذج البنية
تطبيق العميل / SaaS مسار Khatm (إرسال، حقول، PAdES، أدلة) طبقة الثقة (شهادة + مفتاح خاص) ذاتية التوقيع (sandbox) | CA / مزود / HSM (إنتاج) مُتحقق PDF (Adobe وغيره)
فصل مسار العمل (Khatm) عن طبقة الثقة (PKI / HSM / مزود).
PDF bytes → ByteRange → digest (SHA-256)
↓
CMS/PKCS#7 Signature
↓
SignerCert (X.509)
↓
trust path? ──no──→ integrity OK, identity UNTRUSTED
│
yes
↓
trust anchor known → identity TRUSTEDمسار التحقق في قارئ PDF (مجرد)
الضمانات التشفيرية
بغض النظر عن مُصدِر الشهادة، يثبت توقيع PAdES صالح:
- السلامة: أي تعديل على ByteRange الموقّع يبطل التوقيع.
- الأصالة التشفيرية: وُقّعت البصمة بالمفتاح الخاص المطابق للمفتاح العام في الشهادة.
- عدم الإنكار التقني (بالمعنى التشفيري): امتلاك المفتاح الخاص وقت التوقيع، لا اعتراف قانوني تلقائي.
هذه الضمانات لا تعتمد على وسم Adobe للشهادة كموثوقة. تعتمد على التحقق من CMS والبصمة.
مقارنة
| الخاصية | ذاتية التوقيع (اختبار) | صادرة عن CA / مزود (إنتاج) |
|---|---|---|
| سلامة PDF (بصمة) | نعم | نعم |
| Issuer == Subject | نعم | لا (Issuer = CA) |
| مسار إلى مرجع ثقة عام | لا | نعم إن كانت CA في المتجر |
| واجهة Adobe النموذجية | توقيع صالح، هوية غير موثّقة | توقيع + هوية OK |
| الاستخدام | Sandbox وCI وعرض UX/PAdES | نشر العميل وLTV وامتثال المشروع |
| التحكم بالمفتاح الخاص | بيئة اختبار | HSM / KMS / مزود حسب البنية |
شهادة ذاتية التوقيع
Issuer وSubject متطابقان. لا CA وسيطة. مفيدة للتحقق من مسار PAdES دون الاعتماد على PKI.
openssl req -x509 -newkey rsa:2048 -sha256 -days 365 \
-keyout test-signer.key -out test-signer.crt \
-subj "/CN=Khatm Test Signer/O=Sandbox"
# Issuer == Subject → self-signed
openssl x509 -in test-signer.crt -noout -issuer -subjectمثال مفاهيمي: شهادة اختبار (لا تُستخدم في الإنتاج)
شهادة ثقة
تصدر الشهادة عن CA (مؤسسية أو محلية أو مزود ثقة). يبقى المفتاح الخاص تحت HSM أو KMS أو المزود. في الإنتاج يُربط Khatm مشروعاً بمشروع بهذه الطبقة. Khatm لا يصدر شهادات ثقة عامة وليس مزود ثقة مؤهلاً.
- حدد مستوى الإثبات المطلوب (بلد، قطاع، eIDAS / إطار محلي).
- اختر المُصدِر (PKI العميل، مزود، جهاز مؤهل).
- احمِ المفتاح الخاص (HSM/KMS، تدوير، تدقيق).
- تحقق من مسار الثقة في القارئات المستهدفة (متجر Adobe، سياسة المؤسسة).
اعتبارات الأمن
- لا تعِد استخدام شهادة/مفتاح sandbox في الإنتاج.
- افصل البيئات: مفاتيح الاختبار خارج نطاق الإنتاج؛ الأسرار خارج Git.
- احمِ المفتاح الخاص للتوقيع (HSM/KMS، أقل صلاحيات، سجلات عمليات التوقيع).
- تحذير Adobe «هوية غير موثّقة» ليس توقيعاً تشفيرياً باطلاً ولا تعديلاً على PDF.
- لملفات B-T / B-LT: طوابع RFC 3161 وبيانات تحقق (OCSP/CRL) حسب ملف PAdES المستهدف.
- الإلغاء: خطط سياسة OCSP/CRL عندما يتجاوز عمر المستند عمر الشهادة.
معلومات عامة وليست استشارة قانونية. تحقق من متطلبات معاملتك مع المستشار المناسب أو الجهة المستقبلة.
هل الشهادة ذاتية التوقيع ضعيفة تشفيرياً؟
ليس بطبيعتها. تبقى RSA/ECDSA + SHA-256 صالحة. ما ينقص هو مسار ثقة عام إلى مرجع يعرفه المُتحقق.
لماذا يعرض Adobe «هوية غير موثّقة» في العرض؟
لأن السلسلة لا تصل إلى CA في متجر الثقة. قد تبقى سلامة البصمة صالحة مع ذلك.
هل يوفّر Khatm شهادة ثقة عامة؟
لا. يستخدم العرض التجريبي وsandbox شهادة اختبار ذاتية التوقيع. في الإنتاج تُربط PKI أو HSM أو المزود المختار مع العميل.
هل التوقيع في khatm.io مؤهل قانونياً؟
لا. يتحقق العرض التجريبي وsandbox من المسار التقني. Khatm لا يقدّم توقيعاً مؤهلاً أو اعترافاً تنظيمياً.