من 398 يومًا إلى 47: ما الذي تعنيه فترات صلاحية شهادات SSL الجديدة

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

هذا ليس تحديثًا بسيطًا. إن تقليص صلاحية SSL يزيد من تكرار إصدار الشهادات والتحقق من النطاقات والتعامل مع التجديدات. العمليات التي كانت تعمل وفق دورات سنوية لم تعد صالحة في ظل الجداول الزمنية الأكثر صرامة.

تشرح هذه المقالة ما الذي تغيّر، ولماذا اتخذت الصناعة هذه الخطوة، وما الذي يعنيه ذلك عمليًا. ستتعلم أيضًا كيفية التعامل مع هذا التغيير باستخدام أدوات مصممة خصيصًا لعصر أتمتة SSL الجديد.

---

جدول المحتويات

1. الجدول الزمني لصلاحية شهادات SSL: ما الذي تغيّر
2. لماذا تتقلص فترات صلاحية شهادات SSL
3. ما الذي تعنيه صلاحية SSL الأقصر عمليًا
4. فترات الصلاحية الأقصر قادمة أيضًا إلى توقيع الكود
5. كيفية الاستعداد للتغييرات القادمة في صلاحية SSL

---

الجدول الزمني لصلاحية شهادات SSL: ما الذي تغيّر

حدّد CA/Browser Forum جدولًا زمنيًا ثابتًا يُقلّص الحد الأقصى لفترة الصلاحية لشهادات SSL/TLS.

• حتى 14 مارس 2026: كان الحد الأقصى للصلاحية ~398 يومًا
• اعتبارًا من 15 مارس 2026: أصبح الحد الأقصى للصلاحية 200 يوم
• اعتبارًا من 15 مارس 2027: سيصبح الحد الأقصى للصلاحية 100 يوم
• اعتبارًا من 15 مارس 2029: سيصبح الحد الأقصى للصلاحية 47 يومًا

تنطبق هذه الحدود على جميع الشهادات الصادرة عن جهات إصدار الشهادات العامة (CA).

فترات إعادة استخدام التحقق تتغير هي الأخرى

تحدد فترات إعادة استخدام التحقق المدة التي يمكن فيها لجهة CA الاعتماد على التحقق من النطاق المكتمل مسبقًا عند إصدار شهادة SSL جديدة. بعبارة بسيطة، تتحكم الصلاحية في المدة التي تظل فيها الشهادة نشطة، بينما تتحكم إعادة استخدام التحقق في المدة التي يظل فيها إثبات ملكية النطاق مقبولًا لإصدار شهادات جديدة. هذان طبقتان مختلفتان من العملية.

بموجب قواعد CA/Browser Forum الجديدة، تنخفض فترات إعادة استخدام التحقق جنبًا إلى جنب مع فترات صلاحية الشهادات. وهذا يعني أن جهات CA يجب أن تعيد التحقق من التحكم في النطاق بشكل أكثر تكرارًا بدلًا من الاعتماد على سجلات التحقق القديمة. بحلول عام 2029، ستنخفض فترات إعادة الاستخدام إلى 10 أيام فقط، مما يُجبر على إجراء التحقق في كل مرة تقريبًا يتم فيها إصدار شهادة.

• اعتبارًا من 15 مارس 2026: تقتصر إعادة استخدام التحقق على 200 يوم
• اعتبارًا من 15 مارس 2027: تنخفض إلى 100 يوم
• اعتبارًا من 15 مارس 2029: تنخفض إلى 10 أيام

يجب عليك تجديد الشهادات بشكل أكثر تكرارًا وإعادة التحقق من النطاقات بصورة أكثر انتظامًا.

---

لماذا تتقلص فترات صلاحية شهادات SSL

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

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

• الشهادات لقطة في الزمن — تلتقط شهادات SSL ملكية النطاق والبنية التحتية وتفاصيل الاتصال التي كانت دقيقة وقت الإصدار لكنها قد تتغير مع مرور الوقت. تعني فترات الصلاحية الأقصر أن المعلومات القديمة تظل موثوقة لفترة أقل.
• بيانات التحقق تحتاج إلى البقاء محدّثة — تحتاج جهات CA إلى سجلات ملكية نطاق محدّثة لإصدار الشهادات بدقة. إعادة استخدام بيانات التحقق القديمة تزيد من خطر إصدار شهادات استنادًا إلى معلومات لم تعد صحيحة، لذا فإن عمليات الفحص الأكثر تكرارًا تُبقي العملية أمينة.
• فترات الصلاحية الأقصر تُحدّ من التعرض الأمني — أي شهادة صادرة بشكل خاطئ أو مفتاح خاص مخترق لا يمكنه التسبب في ضرر إلا طالما ظل ساريًا. تُقلّص دورات التجديد السريعة تلك النافذة، مما يُحدّ من تداعيات الحوادث التي يستحيل في الغالب منعها كليًا.
• الإدارة اليدوية لا تتوسع — عندما تنتهي صلاحية الشهادات كل أسابيع أو أشهر قليلة، لا تستطيع عمليات التجديد اليدوية ببساطة مواكبة ذلك. تتوقف الأتمتة عن كونها اختيارية — لتصبح الطريقة الواقعية الوحيدة لإدارة الدورة باتساق.

---

ما الذي تعنيه صلاحية SSL الأقصر عمليًا

تكشف الإطارات الزمنية الجديدة للشهادات عن نقاط ضعف في طريقة تتبع الشهادات وإصدارها ونشرها عبر البنية التحتية الفعلية.

التجديدات تصبح عبئًا تشغيليًا

كانت شهادة واحدة تستلزم الاهتمام مرة واحدة في السنة. أما الآن فستستلزم تلك الشهادة ذاتها اتخاذ إجراء ثلاث أو ست أو حتى عشر مرات خلال الفترة نفسها.

خذ إعدادًا نموذجيًا:

• شهادة واحدة على النطاق الرئيسي
• شهادة على API
• شهادة على بيئة الاختبار
• شهادة على الخدمات الداخلية

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

التحقق سيتطلب مزيدًا من الاهتمام

إليك ما ستبدو عليه عملية التجديد النموذجية عند تطبيق القواعد الجديدة:

• تنطلق عملية التجديد متوقعةً الإصدار التلقائي
• تطلب جهة CA تحققًا جديدًا من النطاق
• يجب تحديث سجلات التحقق عبر DNS أو HTTP
• يتوقف خط أنابيب النشر حتى اكتمال التحقق

قم بتوسيع ذلك عبر عشرات النطاقات وبيئات متعددة، وستتوقف التجديدات عن كونها روتينية. تصبح غير متوقعة، وفي الإعدادات المبنية حول خطوط أنابيب CI/CD والنشر التلقائي أو البنية التحتية كرمز، يمكن لخطوة تحقق واحدة غير مؤتمتة أن تُوقف كل شيء.

التتبع اليدوي ينهار في ظل التداخل

تصبح جداول البيانات وتذكيرات التقويم والعمليات المؤقتة أصعب في الصيانة مع زيادة تكرار التجديد.

مثال:

• الشهادة A تنتهي صلاحيتها خلال 60 يومًا
• الشهادة B تنتهي صلاحيتها خلال 45 يومًا
• الشهادة C تنتهي صلاحيتها خلال 30 يومًا

كرر هذا عبر عشرات الشهادات. تتراكم التذكيرات. تتداخل المواعيد النهائية. وقبل أن تدرك ذلك، تبدأ في التفاعل بدلًا من الإدارة. عندما تتنافس أحداث كثيرة في الوقت ذاته، يصبح تفويت موعد انتهاء شهادة أمرًا مرجحًا للغاية.

الشهادات تبدأ في الإفلات من الرقابة

تُقلّل معظم الفرق من تقدير عدد الشهادات التي تُشغّلها فعليًا. غالبًا ما تتضمن البيئة الحقيقية:

• شهادة CDN (الحافة)
• شهادة موازن التحميل
• شهادة خادم الأصل
• شهادات الخدمات الداخلية
• تكاملات الطرف الثالث

لكل منها دورة حياة خاصة بها. بدون اكتشاف أو جرد، تفقد الرؤية. يؤدي ذلك إلى نمط فشل شائع:

• “الموقع الرئيسي يعمل، لكن API يُظهر أخطاء SSL”.
• “الواجهة الأمامية بخير، لكن شهادة الخلفية انتهت صلاحيتها”.

ثغرات النشر تُولّد ثقة زائفة

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

بعد حجم معين، تتوقف إدارة الشهادات عن الاندراج في قائمة مراجعة. تحتاج إلى جرد لتتبع ما هو موجود، ومراقبة لرصد ما يقترب من انتهاء صلاحيته، وأتمتة للتعامل مع التجديدات، ونشر موثوق للتأكد من وصول الشهادات إلى الأماكن الصحيحة.

---

---

فترات الصلاحية الأقصر قادمة أيضًا إلى توقيع الكود

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

تُصدر DigiCert وGoGetSSL الآن شهادات توقيع الكود لمدة عام واحد فقط، مع استخدام العملاء إما وحدة أمان الأجهزة الخاصة بهم أو طلب رمز مادي.

تتبع Sectigo نموذجًا مماثلًا — عام واحد إذا كنت تستخدم رمزًا، لكن تتوفر خيارات لمدة سنة أو سنتين أو ثلاث سنوات إذا كنت تدير المفاتيح من خلال HSM الخاص بك، مثل YubiKey.

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

---

كيفية الاستعداد للتغييرات القادمة في صلاحية SSL

تستلزم صلاحية الشهادات الأقصر عمليات منظمة. يعتمد النهج الصحيح على الحجم والتعقيد.

ACME: الأفضل للأتمتة المستمرة

ACME (Automated Certificate Management Environment) هو بروتوكول موحّد يتيح للخوادم والتطبيقات طلب شهادات SSL/TLS والتحقق منها وإصدارها وتجديدها تلقائيًا. بدلًا من الاعتماد على خطوات يدوية كإنشاء CSR أو الموافقات عبر البريد الإلكتروني أو رفع الملفات، تتفاعل الأنظمة مباشرةً مع جهة CA من خلال سير عمل مدفوعة بـ API.

عمليًا، تتولى شهادات ACME دورة الحياة الكاملة. تُثبت التحكم في النطاق باستخدام تحديات HTTP أو DNS، وتسترد الشهادة وتثبّتها وتجدّدها قبل انتهاء الصلاحية دون تدخل بشري.

تناسب هذا النهج أفضل البيئات التي:

• تتغير فيها البنية التحتية بشكل متكرر (السحابة، الحاويات، الخدمات المصغّرة)
• تعمل فيها عمليات النشر عبر خطوط أنابيب CI/CD
• تتطلب فيها نطاقات أو خدمات متعددة تحديثات مستمرة للشهادات

RapidSSL AutoInstall: أتمتة مبسّطة لإعدادات الخوادم القياسية

يُبسّط AutoInstall SSL إدارة الشهادات في البيئات القائمة على الخوادم. بدلًا من الحاجة إلى رفع يدوي وتعديلات في الإعدادات وخطوات تثبيت متكررة، يتكامل مباشرةً مع لوحات الاستضافة للتعامل مع النشر تلقائيًا.

عمليًا، يعمل ضمن منصات مثل cPanel وPlesk ولوحات الاستضافة المماثلة حيث تُدار الشهادات على مستوى الخادم. بمجرد الإعداد، يمكنه التعامل مع الإصدار والتجديد مع ضمان تثبيت الشهادات وتطبيقها بشكل صحيح دون تدخل يدوي في كل دورة.

يناسب هذا النهج أفضل الإعدادات التي:

• تعتمد فيها الخوادم على لوحات التحكم أو حزم الاستضافة المُدارة
• تتم فيها إدارة الشهادات على مستوى الخادم بدلًا من البنية التحتية المخصصة
• تريد فيها الفرق تقليل أعمال الإعداد المتكررة دون إعادة بناء سير عملها حول الأتمتة المدفوعة بـ API.

DigiCert CertCentral TLS Manager: الأفضل للفرق المتنامية

CertCentral TLS Manager هو منصة مركزية لإدارة دورة الحياة الكاملة لشهادات SSL عبر المؤسسة. يوفر لك واجهة واحدة لإصدار الشهادات وتتبعها وتجديدها واستبدالها من مكان واحد.

يمكنك مراقبة تواريخ انتهاء الصلاحية واكتشاف الشهادات المنشورة بالفعل في البنية التحتية وإدارة التجديدات. كما يدعم الأتمتة من خلال تكاملات API وACME، مما يتيح إصدار الشهادات وتجديدها دون تدخل يدوي مع الحفاظ على التحكم المركزي.

يناسب هذا النهج أفضل البيئات التي:

• تطلب فيها فرق أو أنظمة متعددة الشهادات وتديرها
• لم يعد جرد الشهادات مرئيًا بالكامل
• تبدأ فيها دورات التجديد في التداخل عبر خدمات مختلفة
• يصبح فيها التتبع المركزي والتحكم في السياسات ضروريًا

لا يحل CertCentral محل الأتمتة على مستوى البنية التحتية مثل ACME. بل يُضيف طبقة تحكم فوقها.

DigiCert Trust Lifecycle Manager: الأفضل للمؤسسات الكبيرة

يمتد Trust Lifecycle Manager بإدارة الشهادات إلى ما هو أبعد من SSL/TLS العام ويحوّلها إلى نظام موحّد للتعامل مع الثقة عبر المؤسسة بأكملها. بدلًا من إدارة الشهادات في أدوات معزولة، يجمع الشهادات العامة وPKI الخاصة والهويات الداخلية في إطار عمل واحد خاضع للتحكم.

كما يتكامل مع البنية التحتية للمؤسسات مثل أنظمة الهوية والمنصات السحابية وخطوط أنابيب DevOps، بحيث تصبح عمليات الشهادات جزءًا من سير العمل الحالية بدلًا من كونها عملية منفصلة.

يناسب هذا النهج أفضل البيئات التي:

• يمتد فيها استخدام الشهادات عبر الأنظمة العامة والخاصة
• تدير فيها فرق أو أقسام متعددة شهاداتها الخاصة
• تشمل فيها البنية التحتية إعدادات سحابية ومحلية وهجينة
• تكون فيها متطلبات الحوكمة والامتثال والتدقيق ذات أهمية

على هذا النطاق، لا يكمن التحدي في التجديد فحسب، بل في الرؤية والتحكم والاتساق عبر مئات أو آلاف الشهادات

---

الخلاصة

لقد انتهى رسميًا عصر “اضبطه وانسَه” في أمان الويب. نتجه بعيدًا عن الشهادات التي تدوم لسنوات نحو عالم تنتهي فيه صلاحيتها في غضون أسابيع قليلة فقط.

الساعة تدق بالفعل. الشركات التي لا تزال تحاول التعامل مع هذه التحديثات يدويًا ستشعر بالضغط مع تراكم المواعيد النهائية. في المقابل، الفرق التي تتبنى طريقة عمل أكثر سلاسة وأتمتة لن تكاد تلاحظ التغيير. فترات الصلاحية الأقصر هي الواقع الجديد، والطريق الوحيد للأمام هو التوقف عن التفاعل والبدء في تبسيط العمليات.

تقدم SSL Dragon حلول أتمتة تناسب كل إعداد، من بيئات الخوادم البسيطة إلى البنى التحتية الكبيرة والمعقدة. سواء كنت بحاجة إلى أتمتة قائمة على بروتوكول ACME، أو نشر مبسّط، أو إدارة دورة حياة كاملة، يمكنك اختيار النهج الذي يناسب احتياجاتك والحفاظ على شهاداتك تحت السيطرة مع تسارع دورات التجديد.