اعتبارًا من 15 مارس 2026: تقليص مدة شهادات TLS إلى 200 يوم — الدليل العملي للاستعداد حتى 2029

اعتبارًا من 15 مارس 2026 دخل حيّز التنفيذ أول تخفيض مرحلي لمدد صلاحية شهادات TLS العامة على الويب: الحد الأقصى للإصدار الجديد أصبح 200 يوم بدلًا من 398 يومًا. القرار جزء من خارطة طريق رسمية أقرتها CA/Browser Forum لخفض الصلاحية تدريجيًا حتى 47 يومًا بحلول 15 مارس 2029، مع تقليص مماثل لفترات إعادة استخدام بيانات إثبات التحكم في النطاقات (Domain/IP validation data). هذه ليست «خبرًا عابرًا»، بل تغيير بنيوي يفرض على فرق البنية والمنصات أتمتة دورة الشهادات بالكامل لتفادي الانقطاعات.

ما الذي تغيّر تحديدًا؟

1) الحد الأقصى لصلاحية شهادات TLS

• ابتداءً من 15 مارس 2026 وحتى 14 مارس 2027: لا يجوز أن تتجاوز صلاحية الشهادة 200 يوم (ويُستحسن 199 يومًا لتفادي كسور الثواني).
• من 15 مارس 2027 وحتى 14 مارس 2029: لا يجوز أن تتجاوز 100 يوم.
• اعتبارًا من 15 مارس 2029: الحد الأقصى 47 يومًا.

هذه الجداول واردة صراحة في التعديلات المقترنة بالتصويت المعتمد ضمن وثيقة Baseline Requirements (نسخة SC081v3 الحمراء)، والتي تُحدّد أيضًا طريقة الحساب بالثواني لضبط الحدود بدقة. راجع القسم الخاص بحدود الصلاحية في مستند التعديلات.

2) تقليص فترات إعادة استخدام بيانات التحقق من النطاق/الـIP

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

يعني ذلك أن آليات إثبات التحكم في النطاق (مثل HTTP‑01 وDNS‑01 ضمن ACME) ستحتاج إلى إعادة التحقق بوتيرة أعلى، وإلا سترفض سلطة الإصدار إنشاء شهادة جديدة.

3) اتجاه المتصفحات وبرامج الجذور نحو الأتمتة الصارمة

سياسات متصفّح كروم لجذور الثقة (Chrome Root Program Policy) شهدت خلال 2026 تحديثات تؤكد توقع دعم الأتمتة من جميع جهات الإصدار والمشاركة الفعالة في منظومة الشفافية والتدقيق. هذا يعزّز الرسالة نفسها: إدارة الشهادات يدويًا لم تعد خيارًا آمنًا أو مستدامًا.

من المتأثر؟

• كل المواقع والخدمات التي تستخدم شهادات TLS/SSL عامة موثوقة (على السحابات، خوادم الشركات، واجهات برمجة التطبيقات العامة، متاجر إلكترونية، منصات تعليمية… إلخ).
• المنصات المضيفة التي كانت تبني جداول صيانة نصف سنوية أو سنوية للتجديد اليدوي؛ سيتضاعف عدد دورات التجديد على الأقل، مع نافذة زمنية أصغر لتحديث كل نقاط النهاية.
• بيئات تعتمد شهادات SAN ضخمة لعدد كبير من النطاقات الفرعية؛ ستزداد كلفة إعادة التحقق وتضييق المهلة المسموحة لإعادة استخدام بيانات التحقق.

لماذا يهمّك الآن؟

الانقطاعات الناتجة عن انتهاء شهادة باتت أقرب زمنيًا وأكثر ترجيحًا إذا لم تُؤتمت عملية الإصدار والتجديد وإعادة التحقق. كما أن تقليص فترات إعادة استخدام بيانات التحقق يعني أن أي خلل في مسارات DNS‑01 أو HTTP‑01 أو صلاحيات API مع مقدم الـDNS قد يفشل التجديد في آخر لحظة. بإيجاز: الاعتماد على «تذكير تقويم» لم يعد يكفي؛ يلزمك خط أنابيب آلي resilient مع مراقبة واختبارات ما قبل الإنتاج.

ماذا أفعل الآن؟ خطة تنفيذ عملية بخمس مراحل

1) جرد الأصول وبناء خريطة شهادات دقيقة

• استخرج قائمة بجميع الشهادات العامة في المؤسسة: النطاق، نوع نقطة النهاية (HTTPS، gRPC، WebSocket، بريد)، سلسلة الثقة، تاريخ الانتهاء، وطريقة الإصدار الحالية.
• ارسم اعتماديات الشبكة: موازنات التحميل، بوابات API، WAF، عكس وكلاء، وأي مكونات تُعاد فيها الشهادات أو تُكرَّر.

2) التحول إلى الأتمتة عبر ACME

• اختر مزود ACME موثوقًا (مثل Let's Encrypt أو مزودك التجاري إذا كان يدعم ACME)، وقيّم طريقة التحدي الأنسب: DNS‑01 للبيئات الموزعة أو متعددة المناطق، HTTP‑01 للسيناريوهات البسيطة وراء موازنات تدعم المسارات الخاصة بالتحقق.
• لـ Kubernetes: اعتمد cert-manager مع مُصدِر ACME واذهب إلى DNS challenge لموثوقية أعلى. اختبر تدوير الأسرار (Secrets) وتوزيعها إلى Ingress Controllers قبل بدء نافذة الانتهاء بـ 30 يومًا على الأقل.
• لـ Nginx/Apache على الخوادم: استخدم Certbot أو acme.sh مع سكربتات نشر تُحدِّث مسارات الشهادة والمفتاح وتُعيد تحميل الخدمة دون توقف.
• لـ Windows/IIS: استخدم win‑acme مع مهام مجدولة وواجهات DNS API لمزوّدك.
• على السحابات المُدارة: AWS ACM وCloudFront/ALB، أو Google Cloud Certificate Manager، أو Azure App Service/Front Door تقدّم تجديدًا تلقائيًا لشهاداتها المُدارة؛ تأكد من التغطية لكل النطاقات وخدمات الحافة.

3) تفكيك شهادات SAN الضخمة وتقليل نقاط الفشل

• قسّم الشهادات متعددة النطاقات إلى وحدات أصغر لكل خدمة/نطاق وظيفي؛ هذا يسهّل إعادة التحقق ويقلل خطر فشل تجديد واحد يؤثر على مجموعة نطاقات كاملة.
• استخدم Wildcard بحذر إن كان يناسب حالتك مع DNS‑01، مع حوكمة صارمة لمفاتيح الخصوصية.

4) مراقبة استباقية وإنذارات صلبة

• أنشئ إنذارات متعددة الطبقات: على مستوى المراقبة الداخلية (Prometheus/Alertmanager)، وعلى خدمات مراقبة خارجية من منظور المستخدم، وبمستودع مركزي لتواريخ الانتهاء.
• أضف اختبارات صحة (Health checks) تتأكد من السلسلة الكاملة: وجود الشهادة الصحيحة، تطابق المفاتيح، ودعم الخوارزميات والمتطلبات الحديثة (مثل SCTs وOCSP Stapling حيثما أمكن).

5) حوكمة المفاتيح والمطابقة مع سياسات المتصفحات

• دوّر المفاتيح الخاصة دوريًا وفعّل أذوناتها وفق مبدأ أقل امتياز، مع خزائن مفاتيح أو HSM حيث يلزم.
• تابع سياسات برامج الجذور؛ سياسة Chrome Root Program (إصدار 1.8 في 5 فبراير 2026) شدّدت على متطلبات الأتمتة وتوقعات الحوكمة لدى جهات الإصدار، ما ينعكس على أسلوب إدارتك للشهادات وثقتك بمزوّدك.

خارطة الطريق حتى 2029: ضع المواعيد على التقويم

• 15 مارس 2026 — 14 مارس 2027: أقصى صلاحية 200 يوم؛ إعادة استخدام تحقق النطاق/الـIP حتى 200 يوم.
• 15 مارس 2027 — 14 مارس 2029: أقصى صلاحية 100 يوم؛ إعادة استخدام تحقق النطاق/الـIP حتى 100 يوم.
• اعتبارًا من 15 مارس 2029: أقصى صلاحية 47 يومًا؛ إعادة استخدام تحقق النطاق/الـIP حتى 10 أيام.

إذا كانت مؤسستك لا تزال تعتمد دورات سنوية للتدقيق وإدارة الشهادات، فحدّث سياساتك الآن: اجعل «دورة الشهادة» قصيرة ومؤتمتة بالكامل، وادمج اختبارات التجديد ضمن خط أنابيب CI/CD.

أسئلة تقنية سريعة

هل يؤثر القرار على الشهادات الصادرة قبل 15 مارس 2026؟

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

هل يعني ذلك أن عليّ تغيير مزوّد الشهادات؟

ليس بالضرورة. الأهم أن يوفّر مزوّدك أتمتة ACME أو تكاملًا مكافئًا، وأن يتماشى مع سياسات برامج الجذور الحديثة. راجع تعهدات المزوّد بسياسة Chrome Root Program ومتطلباتها المتعلقة بالأتمتة والشفافية.

لدينا مئات النطاقات الفرعية — ما أفضل نهج؟

قارن بين تجميع النطاقات في شهادات SAN أصغر لكل خدمة، مقابل شهادات Wildcard مع DNS‑01. أيًا كان خيارك، احرص على أتمتة إدارة سجلات TXT لتحدي DNS وراقب تغييرات مزوّد DNS وواجهاته البرمجية، لأن فترات إعادة الاستخدام أقصر الآن.

لماذا اتُّخذ هذا القرار أصلاً؟

المنطق الأمني بسيط: كلما قصرت صلاحية الشهادات وتحديث بيانات التحقق، انخفض خطر الاعتماد على معلومات «قديمة» أو مفاتيح تعرّضت للخطر، وتحسّنت قدرة المنظومة على الاستجابة السريعة لأي ثغرات أو إساءة إصدار. وفي المقابل، تتحمّل المؤسسات مسؤولية الأتمتة والانضباط التشغيلي.

الخلاصة

تقليص مدة شهادات TLS إلى 200 يوم (ثم 100 و47 يومًا) ليس مجرد تعديل شكلي، بل انتقال قسري إلى تشغيل مؤتمت بالكامل لدورة الحياة: إصدار — تحقق — نشر — مراقبة — تدوير. ابدأ اليوم بجرد الأصول، تفعيل ACME، تفكيك شهادات SAN الضخمة، وتهيئة مراقبة استباقية. من يتهيأ جيدًا الآن سيعبر محطتي 2027 و2029 بلا انقطاعات.

المصادر الرسمية

• CA/Browser Forum: Ballot SC081v3 والتصويت والشرح
• Baseline Requirements (SC081v3 - Redline): جداول الصلاحية وإعادة الاستخدام
• Chrome Root Program Policy (v1.8 — 5 Feb 2026)
• DigiCert: أسئلة شائعة حول صلاحية شهادات TLS (تلخيص للمواعيد)