شهادات SSL/TLS — ما تعنيه الحقول والتواريخ النهائيات فعليًا

في وقت ما، كنت تنظر إلى المفتاح الصغير في المتصفح، وتفتح "عرض الشهادة"، ثم تواجه حقلًا كبيرًا يبدو مهمًا لكنه لا يوضح أي شيء: "أسماء المُستخدمين"، "OCSP"، "التوقيع باستخدام التشفير بالـ SHA-256 مع التشفير بالـ RSA". تغلق المحادثة. الشهادة خضراء. هذا كافٍ.

حتى انتهاء صلاحيته. في منتصف الليل في يوم الجمعة. في البيئة الإنتاجية.

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

الشهادة هي مجرد وثيقة موقعة

إزالة الاحتفالات، فإن شهادة TLS هي وثيقة نصية تحتوي على بعض الحقائق — من يمتلك هذا المجال، ما هو المفتاح العام الذي يستخدمه، ومتى تنتهي هذه الوثيقة — وقد تم توثيقها بشكل تشفيري من قبل جهة توثيق (CA). والتوقيع من جهة التوثيق هو ما يجعل المتصفحات تثق بها. كل شيء آخر هو توضيحات.

الصيغة الأساسية تُعرف باسم X.509. تم تحديدها في عام 1988، وتم تحسينها عدة مرات، وتم توضيحها الآن في RFC 5280. وهذا هو السبب الذي يجعل محادثات تفاصيل الشهادات في المتصفحات تبدو وكأنها تم تصميمها من قبل الأشخاص الذين يرون عام 1988 كمُتَحديث.

الحقول الأساسية، المُفسرة

إليك تحليلًا مُوضّحًا للحقول التي ستجدها في شهادة حقيقية. البيانات الخام أدناه مُمثلة (وليس شهادة حية):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

الاسم الشائع (CN)

الحقل الأصلي لتحديد المجال الذي تغطيه الشهادة. ستجد أنك ترى هذا الحقل مملوءًا — CN = example.com — لكن المتصفحات تقلّل من الاعتماد عليه. منذ عام 2000، أصبحت توسعة "أسماء المُستخدمين" هي الحقل المُعتمد لتحديد المجال. أصبح الاسم الشائع تقنيًا مُتَقَلِّد؛ إذا وُجد اسم مُستخدم، فإن المتصفحات تستخدم فقط هذا الاسم.

أسماء المُستخدمين المُتعددة (SAN)

هذا هو القائمة الحقيقية للمجالات التي تُحمي بها الشهادة. يمكن أن تغطي الشهادة عشرات الأسماء — أسماء مُتعددة (*.example.com)، أسماء دقيقة، وحتى عناوين IP. الشهادات المتعددة المجالات (أو الشهادات المُسمّاة SAN أو UCC) هي الممارسة المعيارية. تُصدر الجهة التوثيقية ضد هذه القائمة، وتُطابق المتصفحات اسم الخادم الذي تزوره معها.

شيء واحد يفعله المُتعدّدات إعادة استخدام نوع كائن مثل هو أن يغطي الفروع الفرعية. *.example.com يغطي app.example.com — Python api.v2.example.com. كثير من الناس يكتشفون هذا بطرق صعبة.

مدة الصلاحية

أوقات محددة: قبل البداية و بعد الانتهاء. تكون الشهادة غير صالحة خارج هذه الفترة — قبل تاريخ البداية، بعد انتهاء الصلاحية. كلاهما في الوقت العالمي (UTC).

تم تقليل أقصى مدة صلاحية الشهادات بشكل تدريجي. في عام 2015، كان الأقصى 3 سنوات. في عام 2018، انخفض إلى 2 سنة. في عام 2020، بدأت أبل برفض الشهادات الطويلة أكثر من 398 يومًا (حوالي 13 شهرًا)، مما دفع المطورين والجهات التوثيقية إلى الالتزام. كما أن اللجنة CA/Browser أقرت خطة تقليل هذه المدة إلى 47 يومًا بحلول عام 2027.

السبب وراء تقليل مدة الصلاحية هو منطقي: إذا تم تهديد المفتاح الخاص، فإن الشهادة القصيرة المدة تحد من نطاق التأثير. لكن الواقع التشغيلي هو أن تقليل المدة يزيد الضغط على أنظمة التحديث التلقائي أن تكون صحيحة. كانت شهادات Let's Encrypt بـ 90 يومًا مثيرة للجدل في عام 2015 لسبب مماثل؛ أما الآن فهي مُعدّة كممارسات مثالية، ويُتوقع أن تكون التحديث التلقائي مُتاحة.

المُصدر والسلسلة الموثوقة

ال المصدر يُحدد هذا الحقل الجهة التي وقّعت الشهادة. بالنسبة لمعظم المواقع العامة، هذا هو جهة توثيق متوسطة (مثل R11 من Let's Encrypt)، وليس جهة توثيق جذرية. تُوقّع جهات التوثيق الجذرية شهادات الجهات المتوسطة؛ وتُوقّع الجهات المتوسطة شهادات الأطراف النهائية (التي تُقدّمها الخادم). توجد هذه السلسلة لأن المفاتيح الخاصة للجهات الجذرية تُحتفظ خارج الشبكة في أجهزة مُحمية (HSM)، ولا يمكن التعبير عنها لتوقيع ملايين شهادات المجال سنويًا.

عند تحقق المتصفح من شهادتك، يتحرك عبر السلسلة: شهادتك → جهة متوسطة → جذرية. إذا كانت الجهة الجذرية موجودة في مخزون الثقة في المتصفح، فإن السلسلة تتحقق. إذا كان أي شهادة في السلسلة مفقودة أو مُنتهية الصلاحية أو موقعة بمفتاح مُلغى، فتُرفض التحقق.

هذا هو السبب الذي يجعل التكوين الشائع لـ TLS هو نسيان تقديم الشهادة المتوسطة مع الشهادة الأساسية. قد يُخزن المتصفح المُتوسط، ويبدو أن الأمر مقبولًا، بينما تفشل الأجهزة الأخرى — مثل curl، التطبيقات المحمولة، الخوادم التي تُرسل طلبات خارجية — لأنها لا تمتلك مسارًا للوصول إلى الجذر.

خوارزمية التوقيع

مجمعة في حقل واحد: وظيفة التخزين المُستخدم لدمج بيانات الشهادة، ونوع المفتاح المستخدم لتوقيع هذا التخزين. sha256WithRSAEncryption تعني التخزين باستخدام SHA-256، التوقيع باستخدام RSA. ecdsa-with-SHA256 تعني التخزين باستخدام SHA-256، التوقيع باستخدام ECDSA.

تم تقليل التوقيعات باستخدام SHA-1 من قبل المتصفحات في عام 2017، وتم تسبب في فشل صارم الآن. تم تقليل التوقيعات باستخدام MD5 سابقًا، وتم تجاهله بشكل كامل. إذا كنت تدير أي شيء يُصدر شهادات SHA-1 بشكل داخلي، فتحديث إعدادات جهتك التوثيقية قبل أن يقوم المتصفح بفعل ذلك.

التوقيع باستخدام ECDSA (غالبًا P-256 أو P-384) يُنتج مفاتيح وأوامر أصغر من RSA لمستوى أمان مماثل. مفتاح EC بحجم 256 بت يعادل تقريبًا مفتاح RSA بحجم 3072 بت. التنازل: RSA أكثر توافقًا مع المُستخدمين القديمين؛ ECDSA أسرع وأخف. في التوزيعات الحديثة، غالبًا ما يُحدّد كلا النوعين ويُسمح للتفاوض في TLS بالاختيار.

استخدام المفتاح ووظائف الاستخدام الموسعة

استخدام المفتاح مُحدد بحقل مُحدد ما يمكن أن يُستخدمه المفتاح: التوقيع على البيانات، التشفير على البيانات، التوقيع على شهادات أخرى (مخصص للجهات التوثيقية فقط). الاستخدام الموسّع للاستخدام المُوسّع يُحدد هذا للبروتوكولات المحددة: TLS Web Server Authentication هو ما يسمح باستخدام الشهادة في HTTPS. TLS Web Client Authentication هو ما يُستخدم في شهادات المُستخدمين في mTLS. Code Signing هو ما يُستخدم في شهادات التوقيع البرمجي.

إذا حاولت استخدام شهادة لأغراض خارج استخدام المفتاح المُعلن عنه، فإن المُدخلات الحديثة للـ TLS سترفض ذلك. لا يمكنك استخدام شهادة التوقيع على الكود كمُستخدم على خادم ويب، حتى لو كان الاسم مطابقًا.

القيود الأساسية: CA:FALSE

يحدد هذا الحقل ما إذا كان يمكن استخدام الشهادة لتوقيع شهادات أخرى. CA:FALSE يعني أنه لا يمكن — إنه شهادة نهائية (مُنتهية). CA:TRUE يعني أنه شهادة جهة توثيق، مسموحة لتوقيع شهادات أخرى في السلسلة.

ال pathLenConstraint الذي يظهر أحيانًا مع هذا يخبرك بكم عدد الجهات المتوسطة الموجودة تحت هذا المستوى. غالبًا ما يُحدد الجهة الجذرية هذا لتحديد عمق السلسلة.

OCSP وإلغاء التوثيق

الرابط OCSP (بروتوكول حالة الشهادة عبر الإنترنت) في الشهادة يخبر العميل أين يتحقق من أن الشهادة تم إلغاؤها قبل انتهاء صلاحيتها. يتم إلغاء التوثيق عندما يُهجم المفتاح الخاص أو تم إصدار الشهادة بشكل خاطئ.

في الواقع، يمتلك التحقق من OCSP تاريخًا معقدًا. أوقفت كروم التحقق المباشر من OCSP منذ سنوات، وبدلاً من ذلك استخدمت مجموعات CRL (قائمة مسبقة من الشهادات المُلغاة). يواصل فايرفوكس التحقق من OCSP لكنه يُستخدم بوضع "الإخفاء"، أي أن الشهادة تُعتبر صالحة إذا لم تتمكن من الوصول إلى خادم OCSP. النتيجة: في معظم الشهادات، فإن إلغاء التوثيق في الواقع يُعتبر نظريًا. وهذا أحد الأسباب لاستخدام الشهادات القصيرة المدة — عند 47 يومًا، فإن إلغاء التوثيق يقل لأن الشهادة تنتهي قريبًا.

لماذا تنتهي الشهادات؟

الانتهاء ليس تقلصًا إداريًا. إنه الميكانيزم الذي يحد من مدة صلاحية المُعرف المُهجم. البدائل — مُعرفات دائمة — هي ما تؤدي إلى وجود شهادات SHA-1 ومحفظات جهات توثيق قديمة في البيئة الإنتاجية، وهو ما كان عليه القطاع في عام 2010.

التعويض هو من حيث التشغيل: تقليل المدة يتطلب تلقائيًا. إذا اعتمدت تجديد الشهادة على تذكير مُخطط من مسؤول النظام، فسوف تنتهي في البيئة الإنتاجية في النهاية. الحل الصحيح هو التحديث التلقائي من خلال ACME (بروتوكول Let's Encrypt) أو من خلال واجهة برمجة تطبيقات جهة التوثيق، مع مراقبة تُرسل تنبيهًا عدة أسابيع قبل الانتهاء بدلاً من الليلة التي تنتهي فيها.

كيف تقرأ شهادة التشفير بدون استخدام سطر الأوامر؟

الطريقة القياسية لفحص الشهادة هي openssl x509 -in cert.pem -text -noout، والتي تُنتج ناتجًا مُصاغًا لمن يجد قراءة RFC 5280 صعبة. إذا أردت نفس المعلومات في صيغة لا تتطلب تذكر أوامر openssl، فإن فك تشفير شهادة SSL/TLS و محلل شهادة X.509 على iotools.cloud تأخذ شهادة مُرمّزة بصيغة PEM وتُرجع كل حقل مُصنّف ومرتب — مفيد عند التحقيق من مشكلة سلسلة في منتصف الليل عندما لا يساعد نص openssl.

قد يعجبك أيضاً