14.4.4. الشهادات الموقّعة من جهة تصديق (الموثوق بها عمومياً)¶

تعمل الشهادات ذات التوقيع الذاتي عندما تتحكم بالطرفين معاً. أما إذا كان على عملاء عشوائيين (متصفحات أو هواتف أو برمجيات طرف ثالث) الاتصال بالكاميرا دون أن يُطلب منهم الوثوق بشهادة مخصّصة، فيجب أن تكون الشهادة موقّعة من جهة تصديق (CA) عامة يثق بها أولئك العملاء أصلاً. شيفرة TLS على الكاميرا مطابقة لحالة التوقيع الذاتي -- load_cert_chain مع شهادة ومفتاح بصيغة DER -- وكل ما يتغيّر هو كيفية حصولك على تلك الشهادة.

أهم نقطة على الإطلاق: أنت تولّد المفتاح الخاص بنفسك ولا يغادر جهازك أبداً. جهة التصديق لا تراه أبداً. ما ترسله إلى جهة التصديق هو طلب توقيع شهادة (CSR) -- ملف صغير يحتوي على مفتاحك العام واسم نطاقك -- وما تستعيده هو شهادة (مفتاحك العام واسمك، موقّعان من جهة التصديق). المفتاح والشهادة ملفان منفصلان يُنتَجان بخطوتين منفصلتين؛ ولا تتعامل جهة التصديق إلا مع النصف العام.

المسار العام، وكله يُنفّذ على جهاز عادي (وليس على الكاميرا أبداً):

احصل على اسم نطاق. تصدّق جهات التصديق العامة لاسم DNS تتحكم به (مثل cam.example.com)؛ وهي لن تصدر لعنوان IP مجرّد أو لاسم محلي فقط مثل mycam.
ولّد مفتاحاً و CSR. يُنتج أمر OpenSSL واحد المفتاحَ الخاص و CSR المطابق. استخدم نوع المفتاح نفسه الذي ستستخدمه لشهادة ذات توقيع ذاتي (انظر المفاهيم: الثقة والمفاتيح وصيغة الملف)؛ يُوصى بـ ECDSA P-256.

ECDSA P-256 -- موصى به:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
ECDSA P-384 -- أقوى، أكبر/أبطأ:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
RSA-2048 -- أقصى توافق:
```
openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
احتفظ بـ domain.key سرياً -- فهذا هو ملف المفتاح الذي ستضعه في النهاية على الكاميرا. أما domain.csr فهو الملف الذي تسلّمه إلى جهة التصديق؛ ولا يحتوي على أي أسرار.
قدّم CSR وأثبت تحكّمك بالنطاق. هنا يختلف المساران الشائعان:
- تقوم جهة تصديق ACME آلية مثل Let's Encrypt، المُشغّلة بأداة مثل certbot أو acme.sh، بالخطوتين 2 و 3 نيابة عنك: فهي تولّد المفتاح، وتبني CSR، وتجيب على التحدي تلقائياً (HTTP-01: تقديم رمز عبر المنفذ 80 على النطاق، أو DNS-01: نشر سجل TXT في DNS الخاص به) وتكتب الملفات النهائية.
- جهة تصديق تجارية (تُشترى مباشرةً أو عبر بائع نطاق/استضافة): تلصق نص domain.csr في نموذج ويب، ثم تثبت التحكم بالرد على بريد إلكتروني للتحقق، أو نشر سجل DNS، أو وضع ملف على خادم ويب لذلك النطاق. وبمجرد التحقق تنزّل الملفات الصادرة.
اجمع الملفات الصادرة. لفهم ما تستلمه، يساعد أن تعلم أن الشهادات تشكّل سلسلة ثقة: شهادة نطاقك موقّعة من جهة تصديق وسيطة، التي بدورها موقّعة من جهة تصديق جذرية. كل حلقة تضمن الحلقة الواقعة تحتها. ينتهي بك الأمر إلى:
- مفتاحك الخاص (من الخطوة 2). لم تمتلكه جهة التصديق قط؛ فهو يبقى على جهازك وهو المفتاح الذي تضعه في النهاية على الكاميرا.
- الشهادة الطرفية -- وتُسمّى أيضاً شهادة الكيان النهائي أو الخادم. هذه هي الشهادة الخاصة بنطاقك المحدد (cam.example.com): فهي تحتوي على مفتاحك العام واسمك، وموقّعة من الشهادة الوسيطة لجهة التصديق. هذه هي الشهادة التي تقدّمها الكاميرا لتعريف نفسها.
- واحدة أو أكثر من الشهادات الوسيطة لجهة التصديق ("السلسلة" أو "حزمة جهة التصديق"). لا توقّع جهة التصديق شهادتك الطرفية بجذرها مباشرةً -- إذ يُحفظ مفتاح الجذر دون اتصال ومحمياً بشدة -- لذا توقّع بشهادة وسيطة، تكون هي نفسها موقّعة من الجذر. الشهادة الوسيطة هي الحلقة التي تربط شهادتك الطرفية صعوداً إلى الجذر.
الشهادة الجذرية هي مرساة الثقة: شهادة ذات توقيع ذاتي تخص جهة التصديق وتقع في قمة السلسلة. لا تُعطى لك ولا تنشرها أبداً، لأن كل عميل يملكها أصلاً -- فأنظمة التشغيل والمتصفحات والهواتف وبيئات تشغيل اللغات تأتي بـ "مخزن ثقة" مدمج للشهادات الجذرية. يثق العميل بشهادتك الطرفية بالسير عبر السلسلة: فهو يثق أصلاً بالجذر، والجذر يضمن الشهادة الوسيطة، والشهادة الوسيطة تضمن شهادتك الطرفية. (هذه بالضبط هي الوظيفة التي يؤديها ملف server.der / cafile الوحيد لديك في حالة التوقيع الذاتي -- فهناك تكون أنت جذرك الخاص.)

ملف السلسلة الكاملة (fullchain) هو ببساطة الشهادة الطرفية والشهادة (الشهادات) الوسيطة مدمجة في ملف واحد، الطرفية أولاً، مع تعمّد عدم تضمين الجذر (إرسال الجذر بلا جدوى -- فالعميل لا يثق إلا بالجذور التي يملكها أصلاً). يقدّم الخادم العادي هذه السلسلة الكاملة بأكملها حتى يتمكن أي عميل من السير عبرها. لا تستطيع الكاميرا ذلك: فهي تحمّل وتقدّم شهادة واحدة -- الطرفية -- ولا يمكنها أيضاً إرسال الشهادة (الشهادات) الوسيطة التي أعطتك إياها جهة التصديق.

أسماء الملفات التي ستراها فعلاً: تكتب أداة ACME مثل certbot الملفات privkey.pem (مفتاحك) و cert.pem (الشهادة الطرفية وحدها) و chain.pem (الشهادة (الشهادات) الوسيطة وحدها) و fullchain.pem (الطرفية + الوسيطة (الوسيطة)). أما جهة التصديق التجارية فتعطيك عادةً ملف .crt للشهادة الطرفية وملف .ca-bundle للشهادة (الشهادات) الوسيطة، مع كون .key هو الملف الذي ولّدته بنفسك.
حوّل وانسخ. حوّل المفتاح الخاص والشهادة الطرفية إلى DER وانسخهما إلى الكاميرا تماماً كما في الشهادات الموقّعة ذاتياً. ثم تقدّمهما الكاميرا كشهادة خادمها ويقبل العملاء القياسيون الاتصال تلقائياً، لأنهم يثقون أصلاً بجهة التصديق -- ولا حاجة لأي تهيئة من جانب العميل.

نصيحة

عملياً، يجري تقديم الكاميرا للشهادة الطرفية فقط (ولا تقدّم الشهادات الوسيطة أبداً) على هذا النحو:

العملاء الذين يملكون أصلاً الشهادة الوسيطة لجهة التصديق مخزّنة مؤقتاً -- وهو ما تفعله عادةً المتصفحات الرئيسية ومكتبات HTTPS -- يكمّلون السلسلة بأنفسهم ويتصلون بشكل سليم.
العملاء الذين يعتمدون على الخادم لتوفير الشهادة الوسيطة سيفشلون في المصافحة مقابل الكاميرا.

إذا كان يجب أن ينجح كل عميل ممكن، فلا تُنهِ TLS العام على الكاميرا مباشرةً. ضع بوابة / وكيلاً عكسياً أمامها يقدّم السلسلة الكاملة إلى العالم الخارجي، واجعل الوكيل يصل إلى الكاميرا عبر مسار التوقيع الذاتي الموصوف أعلاه.