لماذا تقصر مدة الشهادات
اعتمد منتدى CA/B، الهيئة التي تجمع سلطات التصديق ومطوّري المتصفحات، في أبريل 2025 الاقتراع SC-081v3. وهو ينظّم تقليصًا تدريجيًا لمدتين: صلاحية الشهادات، والفترة التي يمكن خلالها إعادة استخدام التحقق من النطاق. وقد صوّتت Apple وGoogle وMicrosoft وMozilla جميعها بالموافقة. الهدف مزدوج: الحدّ من تعرّض مفتاح مخترق أو شهادة صدرت خطأً، وإلزام البنى التحتية بالتجديد المتكرر، أي بالأتمتة. نادرًا ما تُلغى شهادة صالحة لسنة في الوقت المناسب عند تسرّب مفتاحها، أما شهادة مدتها ستة أسابيع فتنتهي من تلقاء نفسها قبل أن تُحدث ضررًا كبيرًا. والقطاع يسير في الاتجاه نفسه: في 2026 فتحت AWS Certificate Manager نقطة وصول ACME تُصدر شهادات عامة مدتها 45 يومًا. ولا يقلّص تقصير مدة الصلاحية سطح الهجوم إلا بشرط واحد: أن يكون التجديد موثوقًا وآليًا ومراقَبًا. وهذا ما يضعه هذا الدليل موضع التنفيذ.
المخاطر الفعلية للتجديد اليدوي
- انتهاء صامت للصلاحية — تعتمد الشهادة المجدَّدة يدويًا على تنبيه في التقويم أو تذكير بشري، وهما آليتان تفشلان بانتظام في فترات الضغط أو عند تغيّر الفريق.
- تنبيهات متأخرة — تنبّه أدوات المراقبة التقليدية قبل 30 يومًا من انتهاء الصلاحية، وهي عتبة صُمّمت لشهادات مدتها سنة؛ أما مع شهادة مدتها 64 يومًا فيصل التنبيه بعد أن تكون قد استهلكت أكثر من نصف عمرها.
- لا مزيد من التذكيرات بالبريد — توقفت Let's Encrypt عن إرسال رسائل التحذير من انتهاء الصلاحية في 4 يونيو 2025؛ فإن لم يراقب شيءٌ شهاداتك، فلن ينبّهك أحد بعد الآن.
- إعدادات تشفير جامدة — يدفع التجديد اليدوي إلى تكرار الإعدادات نفسها، بينما تفرض الأتمتة سياسة مفاتيح تُطبَّق في كل مرة.
- أثر على التزامات الخدمة — يرتّب انقطاع ناتج عن شهادة منتهية الصلاحية مسؤولية تعاقدية ويضرّ بسمعة المنصة.
- عبء تشغيلي متزايد — عند التجديد بعد ثلثي مدة الصلاحية، تُجدَّد شهادة مدتها 64 يومًا نحو ثماني مرات في السنة، ونحو اثنتي عشرة مرة عند 45 يومًا، دون أي قيمة مضافة للفريق.
الجدول الزمني لمنتدى CA/B: 200 ثم 100 ثم 47 يومًا
تحدّد المتطلبات الأساسية (Baseline Requirements) المدة القصوى لشهادة خادم عامة، أيًّا كانت السلطة التي تُصدرها. منذ 15 مارس 2026 أصبحت 200 يوم بعد أن كانت 398. وفي 15 مارس 2027 ستنخفض إلى 100 يوم. وفي 15 مارس 2029 ستبلغ 47 يومًا. وتتبع الفترة التي يمكن فيها للسلطة إعادة استخدام تحقق سابق من النطاق المنحنى نفسه: 200 يوم، ثم 100 يوم، ثم 10 أيام فقط. هذا المنحنى الثاني هو الأقل تناولًا والأكثر تقييدًا: فهو يعني أن عميل ACME لديك سيضطر إلى إثبات السيطرة على النطاق في كل تجديد تقريبًا. وإن كان التحقق لديك يعتمد على سجل DNS يُضاف يدويًا، أو على منفذ 80 لا يُفتح إلا بين حين وآخر، فهذا ما سينكسر أولًا. والشهادات التجارية المشتراة اليوم محدودة أصلًا بـ 200 يوم: التغيير ليس قادمًا، بل بدأ بالفعل.
Let's Encrypt تنتقل إلى 64 يومًا: التواريخ المهمة
أعلنت Let's Encrypt في 7 أكتوبر 2026 جدولًا زمنيًا أسرع من السقف التنظيمي. منذ 14 أكتوبر 2026 تُصدر بيئة staging لديها شهادات مدتها 64 يومًا لتتمكّن من الاختبار. وفي 10 فبراير 2027 ستكون صلاحية كل شهادة تُصدر أو تُجدَّد في الإنتاج بالملف الافتراضي classic مدتها 64 يومًا، وستنخفض إعادة استخدام التفويضات من 30 إلى 10 أيام. ومن المتوقع أن تنتهي آخر شهادة مدتها 90 يومًا نحو 11 مايو 2027. وفي 16 فبراير 2028 سينتقل الملف الافتراضي إلى 45 يومًا، مع خفض إعادة استخدام التفويضات إلى 7 ساعات. وتوجد ملفات اختيارية منذ الآن: tlsserver يُصدر شهادات مدتها 45 يومًا، وshortlived شهادات مدتها نحو ستة أيام. وتوضّح Let's Encrypt أن الشهادات الصالحة لن تُلغى، وأن حدود المعدّل لا تتغيّر، وأن نقاط وصول ACME وسلاسل الإصدار تبقى كما هي.
جدول مرجعي: ما الذي يتغيّر ومتى
مرّر الجدول أفقيًا
| الموعد | التغيير | ما يجب أن تتحقق منه |
|---|---|---|
| 15 مارس 2026 | سقف منتدى CA/B عند 200 يوم | شهاداتك التجارية السنوية محدودة أصلًا |
| 14 أكتوبر 2026 | بيئة staging لدى Let's Encrypt بـ 64 يومًا | سلسلة التجديد لديك تنجح أمام staging |
| 10 فبراير 2027 | الملف `classic` بـ 64 يومًا، والتفويضات قابلة لإعادة الاستخدام 10 أيام | لا مهلة مثبّتة على 60 أو 80 أو 83 يومًا |
| 15 مارس 2027 | سقف منتدى CA/B عند 100 يوم | تجديد آلي لدى جميع سلطاتك |
| 11 مايو 2027 | الانتهاء المتوقع لآخر شهادة Let's Encrypt مدتها 90 يومًا | لا شهادة بمدة 90 يومًا في الجرد |
| 16 فبراير 2028 | الملف `classic` بـ 45 يومًا، والتفويضات قابلة لإعادة الاستخدام 7 ساعات | نجاح التحقق من النطاق عند كل تجديد |
| 15 مارس 2029 | سقف منتدى CA/B عند 47 يومًا، والتحقق قابل لإعادة الاستخدام 10 أيام | مراقبة انتهاء الصلاحية على كامل الخوادم |
ما الذي يتغيّر في منطق التجديد
القاعدة التي ينبغي تذكّرها بسيطة: جدّد عند ثلثي مدة الصلاحية، لا بعد عدد ثابت من الأيام. مع 64 يومًا يعني ذلك التجديد نحو اليوم 43، مع هامش ثلاثة أسابيع لإصلاح أي عطل. أما مهمة cron مضبوطة على «التجديد كل 60 يومًا» فلن تترك سوى أربعة أيام من الهامش، ومع شهادة مدتها 45 يومًا ستأتي بعد انتهاء الصلاحية. وتوصي Let's Encrypt بالبحث في جداول crontab والسكربتات وإجراءات التشغيل عن القيم المثبّتة مثل 60 أو 80 أو 83. والرافعة الثانية اسمها ARI، اختصار ACME Renewal Information، المعتمدة في RFC 9773: إذ تُبلغ السلطة نفسها عميلك بنافذة التجديد. فإن كان عميلك يدعمها، فإنه يتبع المدد الجديدة تلقائيًا، ويجدّد مبكرًا إذا اضطرت السلطة إلى إلغاء شهادات على نطاق واسع. هذا هو الإعداد الذي توصي به Let's Encrypt: مع تفعيل ARI لا يتطلّب إعلان الـ 64 يومًا أي إجراء من جانبك.
قائمة تحقق للأتمتة، عميلًا بعد عميل
جرد الشهادات القائمة
أحصِ كل شهادة نشطة: النطاقات المشمولة، والسلطة المُصدِرة، وتاريخ الانتهاء، وطريقة التحقق (HTTP-01 أو DNS-01 أو TLS-ALPN-01)، والعميل الذي يجدّدها. يعرض الأمر
certbot certificatesالشهادات التي يديرها certbot. أما البقية فيعرض الأمرecho | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | openssl x509 -noout -issuer -datesالجهة المُصدِرة وتواريخ الصلاحية. سجّل أيضًا الشهادات المنسوخة يدويًا إلى موازن أحمال أو NAS أو جهاز شبكي: فهي التي تنتهي صلاحيتها بصمت.التأكد من أن عميلك يدعم ARI
يدعم certbot بروتوكول ARI منذ الإصدار 4.1.0، و
acme.shمنذ الإصدار 3.1.4 حيث يكون مفعّلًا افتراضيًا. ويدمجه Caddy منذ الإصدار 2.8. تحقّق من الإصدار المثبّت بالأمرcertbot --versionأوacme.sh --version. قد توفّر توزيعة قديمة إصدارًا أقدم من certbot: ثبّت حينها حزمة snap التي توصي بها EFF، أو بيئة Python مخصّصة، بدل الإبقاء على إصدار يتجاهل النافذة التي تقترحها السلطة.certbot: إزالة المهل المثبّتة
منذ الإصدار 4.0.0 يجدّد certbot افتراضيًا عندما يتبقّى ثلث مدة الصلاحية، ويمكن لـ ARI تقديم هذا الموعد. افتح الملف
/etc/letsencrypt/renewal/your-domain.com.confواحذف أي قيمةrenew_before_expiryقصيرة جدًا موروثة من دليل قديم: من دونها تُطبَّق قاعدة الثلث. تحقّق من أن المجدول يعمل بالأمرsystemctl list-timers | grep certbot. وللانتقال إلى 45 يومًا من الآن، يطلب الخيار--preferred-profile tlsserverهذا الملف عند الإصدار.acme.sh: دع ARI يقرّر
منذ الإصدار 3.1.4 يتبع
acme.shنافذة ARI لدى السلطة، وتعمل مهمة cron الخاصة به كل ست ساعات؛ ويعيد الأمرacme.sh --install-cronjobتثبيتها إن اختفت. احذر الفخ المعاكس: منذ الإصدار 3.1.5 يتقدّم خيار--daysأو--valid-toالصريح على ARI. لذا فإن أمر إصدار قديمًا يتضمّن--days 60سيفرض التجديد في اليوم 60 من شهادة مدتها 64 يومًا. احذفه، ثم تحقّق من موعد التجديد القادم بالأمرacme.sh --list.Caddy: التحقق من التخزين والمنافذ
يدير Caddy بروتوكول ACME أصليًا، ويجمع بين ARI والمدة الفعلية للشهادة وحالة إلغائها ليقرّر موعد التجديد: لا حاجة لأي إعداد لاستيعاب 64 ثم 45 يومًا. النقطتان اللتان يجب التحقق منهما في مكان آخر. يجب أن يكون دليل بيانات Caddy دائمًا، وإلا فكل إعادة إنشاء للحاوية تطلب الشهادات من جديد وتصطدم في النهاية بحدّ المعدّل. ويجب أن يبقى المنفذ 80، أو المنفذ 443 لطريقة TLS-ALPN-01، متاحًا من الإنترنت لإتمام التحقق.
Traefik: لا تُفسد certificatesDuration
يخطّط Traefik لعمليات التجديد انطلاقًا من الخيار
certificatesDurationالمعبَّر عنه بالساعات. وقيمته الافتراضية2160(90 يومًا) تُطلق التجديد قبل 30 يومًا من الانتهاء: مع شهادة مدتها 64 يومًا يقع ذلك نحو اليوم 34، بهامش مريح. لا تنسخ قيمة وجدتها في دليل قديم: فبحسب التوثيق، لا تُطلق مدة مُعلنة بين 7 و30 يومًا التجديد إلا قبل يوم واحد من الانتهاء. وأخيرًا احفظ الملفacme.jsonعلى وحدة تخزين دائمة، بالصلاحيات600.nginx: أتمتة إعادة التحميل
لا يعيد nginx قراءة شهادة مجدَّدة ما لم يُعَد تحميله: لذلك قد يُبقي تجديد ناجح الشهادة القديمة في الخدمة حتى انتهاء صلاحيتها. مع certbot، ضع في الدليل
/etc/letsencrypt/renewal-hooks/deploy/سكربتًا قابلًا للتنفيذ يحتوي علىnginx -t && systemctl reload nginx، أو مرّر--deploy-hook "systemctl reload nginx"عند الإصدار. ومعacme.sh، يحفظ الخيار--reloadcmd "systemctl reload nginx"التابع لـ--install-certالأمر لعمليات التجديد اللاحقة. كما يوفّر NGINX وحدة ACME أصلية هيngx_http_acme_module.الاختبار أمام بيئة staging
شغّل سلسلتك أمام بيئة staging التي تُصدر أصلًا شهادات مدتها 64 يومًا وحدود معدّلها أوسع بكثير. مع certbot، يمرّ الأمر
certbot renew --dry-runعبر staging دون المساس بشهاداتك؛ ولا يستعلم هذا الوضع عن ARI. وللحصول على شهادة اختبار حقيقية، استخدم--test-certعلى نطاق غير حرج. ومعacme.sh، أضف--staging. ومع Caddy أو Traefik، وجّه السلطة إلىhttps://acme-staging-v02.api.letsencrypt.org/directory، ثم تحقّق من المدة بالأمرopenssl x509 -noout -dates -in cert.pem.مراقبة انتهاء الصلاحية وربط بقية الخوادم
التجديد الآلي الذي يفشل بصمت أسوأ من التجديد اليدوي. أضف خطّاف نشر يُرسل إشعارًا إلى قناة تنبيه عند كل تجديد ناجح، ومسبارًا مستقلًا يقيس يوميًا الأيام المتبقية على الشهادة المقدَّمة فعلًا. واضبط التنبيه على نسبة من مدة الصلاحية، مثل أقل من ربع الصلاحية المتبقية، بدل 30 يومًا ثابتة. وللإعداد الأولي على خادم VPS، يشرح دليلنا عن شهادات SSL مع Let's Encrypt طرق HTTP-01 وDNS-01 وشهادات wildcard.
لا تفترض أبدًا أن إعداد التجديد يعمل قبل أن تراه يعمل. قبل 10 فبراير 2027 بعدة أسابيع، شغّل certbot renew --force-renewal --cert-name your-domain.com على نطاق غير حرج، ثم تحقّق بالأمر openssl s_client من أن الخادم يقدّم الشهادة الجديدة فعلًا. يستغرق الاختبار دقائق قليلة ويُقصي العطل الأكثر شيوعًا: شهادة جُدّدت على القرص ولم يُعِد أحد تحميلها.
استكشاف الأخطاء: رسائل الخطأ الأكثر شيوعًا
Timeout during connect (likely firewall problem)— لم تتمكّن السلطة من الوصول إلى خادمك عبر المنفذ 80 (HTTP-01) أو 443 (TLS-ALPN-01). افحص الجدار الناري بالأمرufw status، وقواعد الشبكة لدى المزوّد، وسجل AAAA: فعنوان IPv6 منشور لكنه لا يخدم الطلبات يكفي لإفشال التحقق.Invalid response from http://your-domain.com/.well-known/acme-challenge/…: 404— ملف التحدّي لا يُقدَّم. السبب المعتاد إعادة توجيه في غير موضعها، أو كتلةlocationواسعة جدًا، أو وكيل عكسي يحيل كل شيء إلى التطبيق؛ استثنِ/.well-known/acme-challenge/من هذه القواعد.CAA record for your-domain.com prevents issuance— سجل DNS من نوع CAA لا يأذن لهذه السلطة. أضف0 issue "letsencrypt.org"إلى المنطقة، أو اسم السلطة التي تستخدمها فعلًا.too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s— بلغ سكربت يفرض التجديد في حلقة حدّ خمس شهادات متطابقة في الأسبوع. انتظر حتى الموعد المذكور بعدretry after، وأجرِ اختباراتك في staging.- ما زال المتصفح يعرض تاريخ الانتهاء القديم — جُدّدت الشهادة على القرص لكن خادم الويب لم يُعَد تحميله. افحص خطّاف النشر، ثم قارن نتيجة
openssl x509 -noout -enddateعلى الملف وعلى الاتصال الفعلي.
للتعمّق أكثر
الانتقال إلى 64 يومًا ليس حدثًا يُستعدّ له مرة واحدة: إنه درجة في سلّم ينزل حتى 45 يومًا لدى Let's Encrypt و47 يومًا لدى جميع السلطات. والبنية التحتية التي تجدّد عند الثلثين، وتصغي إلى ARI، وتعيد تحميل خدماتها، وتراقب الشهادة المقدَّمة فعلًا، ستعبر كل الدرجات دون تدخّل. إن كنت تبدأ مع Let's Encrypt على خادم VPS، فمقالنا عن شهادات SSL مع Let's Encrypt يشرح الإعداد الأولي والحالات الخاصة بشهادات wildcard. وللبنى التحتية الجديدة، يستحق Caddy اهتمامًا خاصًا: فدعمه الأصلي لـ ACME يلغي طبقة إدارة الشهادات بالكامل. وأخيرًا، إن كان التحقق لديك يعتمد على DNS-01، فاقصر رمز واجهة DNS البرمجية على المنطقة المعنية وحدها: فمع تحقق لا يُعاد استخدامه إلا عشرة أيام، سيُستعمل هذا الرمز في كل تجديد تقريبًا.
