أعمار شهادات TLS تتقلص إلى 47 يوماً: جدول منتدى CA/Browser وما يجب أتمتته

يتقلص الحد الأقصى لعمر شهادة TLS الموثوقة علناً بشكل كبير. فبموجب القرار SC-081v3 الذي اعتمده منتدى CA/Browser في أبريل 2025، ينخفض الحد من 398 يوماً إلى 47 يوماً على ثلاث مراحل بين مارس 2026 ومارس 2029. والمرحلة الأولى سارية بالفعل: الشهادات الصادرة منذ 15 مارس 2026 لا تتجاوز صلاحيتها 200 يوم.

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

الجدول الزمني

التواريخ أدناه مأخوذة من القسم 6.3.2 من المتطلبات الأساسية (Baseline Requirements) لمنتدى CA/Browser (الإصدار 2.3.1 وقت كتابة المقال)، وهي متطلبات تلتزم بها كل جهة إصدار شهادات عامة تثق بها المتصفحات الرئيسية.

هناك تفصيلان مهمان عملياً. الأول أن المتطلبات تنص على أنه لا ينبغي للجهات المصدرة الإصدار بكامل المدة المسموحة، لذا توقع أعماراً تقل بيوم تقريباً عن كل حد. والثاني أن عمود "إعادة الاستخدام" يعني المدة التي يجوز فيها للجهة المصدرة الاعتماد على إثبات سابق لملكيتك للنطاق. ومن مارس 2029 لن يتجاوز عمر هذا الإثبات 10 أيام، أي أن التحقق من النطاق سيحدث فعلياً مع كل تجديد. أما بيانات المنشأة في شهادات OV وEV فقد انخفضت مدة إعادة استخدامها من 825 إلى 398 يوماً في 15 مارس 2026.

من قرر ذلك وما الذي يشمله

أُقرّ القرار في مجموعة عمل شهادات الخوادم في المنتدى بتصويت 25 جهة إصدار بالموافقة دون أي رفض مع امتناع خمس جهات، وبموافقة جميع مستهلكي الشهادات الأربعة (Apple وGoogle وMicrosoft وMozilla)، كما هو موثق في صفحة القرار.

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

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

قواعد مرتبطة قد توقف الإصدار

• تحقق الجهات المصدرة من DNSSEC (منذ 15 مارس 2026). يجب على الجهات المصدرة التحقق من DNSSEC عند فحص ملكية النطاق وسجلات CAA، ولا يجوز اعتبار فشل التحقق مثل SERVFAIL إذناً بالإصدار. أي أن النطاق الذي يعاني خللاً في DNSSEC لن يتمكن من الحصول على شهادة أو تجديدها.
• معاملات CAA (من 15 مارس 2027). يجب على الجهات المصدرة معالجة المعاملين accounturi وvalidationmethods المعرّفين في RFC 8657، فتصبح السجلات التي تستخدمهما ملزمة لدى الجميع.
• التحقق من النطاق عبر البريد الإلكتروني (ينتهي في 15 مارس 2028). لن يُسمح بعد ذلك بطرق إثبات الملكية عبر رسالة إلى عنوان مثل admin@ أو إلى جهة اتصال منشورة في DNS. إذا كان مورد شهاداتك يتحقق منك بالبريد اليوم، فاسأله عن البديل.

ماذا يعني ذلك لخوادمك

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

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

اعرف ما لديك

تحقق من جهة الإصدار وتاريخ الانتهاء لأي نقطة وصول عامة:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -enddate

وللحصول على تنبيه بسيط إذا كانت الشهادة ستنتهي خلال 14 يوماً (1,209,600 ثانية) استخدم الخيار -checkend:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 1209600 && echo "OK" || echo "Expires within 14 days"

نفّذ الفحص لكل اسم مضيف تملكه، بما في ذلك البريد (المنفذ 465 أو 993) وأي خدمة غير الويب، واحفظ القائمة في أداة مراقبة بدلاً من جدول بيانات.

أتمتة الإصدار والتجديد

الطريقة المعيارية للأتمتة هي بروتوكول ACME (المعيار RFC 8555) الذي تدعمه Let's Encrypt وكثير من الجهات التجارية. على Debian وUbuntu تثبّت حزمة Certbot من مستودعات التوزيعة مؤقِّت systemd يشغّل التجديد مرتين يومياً. تأكد من أنه يعمل وأن التجديد ينجح من البداية إلى النهاية:

systemctl list-timers certbot.timer
sudo certbot certificates
sudo certbot renew --dry-run

التجديد نصف المهمة فقط، إذ يجب أيضاً تحميل الشهادة الجديدة. تأكد من وجود خطاف نشر (deploy hook) يعيد تحميل الخدمة التي تستخدمها، مثل --deploy-hook "systemctl reload nginx". وتجنّب السكربتات التي تجدد بعد عدد ثابت من الأيام (كل 60 أو 80 يوماً مثلاً)؛ جدّد عند ثلثي العمر تقريباً، أو استخدم عميلاً يدعم ACME Renewal Information (ARI) الذي يتيح للجهة المصدرة إبلاغ العميل بموعد التجديد.

أمور يجب تجنبها

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

ما الذي ينبغي فعله

• أعدّ قائمة بكل شهادة تعتمد عليها مع جهة إصدارها وتاريخ انتهائها وطريقة تجديدها.
• انقل التجديد اليدوي إلى أتمتة ACME الآن، ما دام الحد 200 يوم والأخطاء قليلة الكلفة.
• اختبر التجديد بالأمر certbot renew --dry-run (أو ما يقابله في عميلك) وتأكد من إعادة تحميل الخدمة بعده.
• أضف مراقبة لتواريخ الانتهاء مع تنبيهات قبل 14 يوماً على الأقل.
• إن كنت تستخدم DNSSEC فتأكد من سلامة التحقق، وإن كان موردك يتحقق من النطاقات بالبريد فاسأله عن البديل قبل مارس 2028.

في خطط الاستضافة لدى Skyline Cloud تُصدر شهادات SSL وتُجدد تلقائياً، أما على خادم VPS تديره بنفسك فإعداد التجديد ومراقبته جزء من إدارة الخادم.

المصادر

• cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data...
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md
• letsencrypt.org/2025/12/02/from-90-to-45
• manpages.debian.org/trixie/openssl/openssl-x509.1ssl.en.html
• packages.debian.org/trixie/all/certbot/filelist
• cloud.alskyline.com/hosting