Let’s Encrypt اعلام کرده است که از ۱۰ فوریه ۲۰۲۷، گواهی‌های جدید آن به‌جای ۹۰ روز، ۶۴ روز اعتبار خواهند داشت و این مدت در ۲۰۲۸ به ۴۵ روز کاهش می‌یابد. این تغییر اگرچه می‌تواند امنیت را بهبود دهد، اما برنامه‌های تمدید خودکار (Automatic Renewal) را به چالشی جدی تبدیل می‌کند؛ به‌ویژه برای ابزارهایی که تاریخ تمدید را به‌صورت ثابت در تنظیمات یا اسکریپت‌ها نگه داشته‌اند.
تغییر اصلی: گواهی کوتاه‌تر، تمدید حساس‌تر
بر اساس اعلام Let’s Encrypt، گواهی‌هایی که در یا پس از ۱۰ فوریه ۲۰۲۷ صادر شوند ۶۴ روز اعتبار دارند. آخرین گواهی ۹۰ روزه حدود ۱۱ مه ۲۰۲۷ منقضی می‌شود و دوره استفاده مجدد از مجوز (Authorization Reuse Period) نیز از ۳۰ روز به ۱۰ روز کاهش پیدا می‌کند. محیط آزمایشی (Staging Environment) این مرجع صدور گواهی از ۱۴ اکتبر ۲۰۲۶ صدور گواهی‌های ۶۴ روزه را آغاز کرده است، بنابراین امکان تست سازگاری از همین حالا وجود دارد.
نکته مهم برای مدیران سیستم، نحوه زمان‌بندی تمدید است. کلاینت‌هایی که از ACME Renewal Information یا ARI پشتیبانی می‌کنند، می‌توانند زمان تمدید را از خود مرجع صدور گواهی دریافت کنند. اما هر ابزاری که روی تعداد روز ثابت تنظیم شده باشد، باید به تمدید در حدود دو سوم طول عمر گواهی تغییر کند. Let’s Encrypt حتی پیشنهاد کرده است که cron jobها و اسکریپت‌ها برای اعداد ۶۰، ۸۰ یا ۸۳ بازبینی شوند.
چرا تمدید هر ۶۰ روز دیگر کافی نیست؟
در یک گواهی ۶۴ روزه، زمان‌بندی تمدید هر ۶۰ روز فقط چهار روز فاصله ایمنی باقی می‌گذارد؛ این فاصله در صورت بروز اختلال در سرویس DNS یا تأخیر در صدور گواهی بسیار کم است. در گواهی ۴۵ روزه، همان زمان‌بندی ۶۰ روزه عملاً پس از انقضای گواهی اجرا می‌شود. قانون دو سوم برای گواهی ۶۴ روزه حدود روز ۴۳ و برای گواهی ۴۵ روزه حدود روز ۳۰ را پیشنهاد می‌کند.
آزمون عملی با Caddy، Proxmox و Synology DSM
نویسنده XDA Developers برای بررسی این تغییر، سه سرویس پرکاربرد در آزمایشگاه خانگی خود را آزموده است: پروکسی معکوس (Reverse Proxy) مبتنی بر Caddy، سرور Proxmox VE و NAS ساخت Synology با سیستم‌عامل DSM. هدف این بوده که هر سه سرویس نه فقط روی کاغذ، بلکه در عمل توانایی کار با گواهی ۶۴ روزه را نشان دهند.
Caddy: آماده از قبل
در این آزمایش، Caddy نسخه 2.11.4 برای دامنه داخلی آزمایشگاه یک گواهی Wildcard از طریق Cloudflare DNS API صادر می‌کرد. Caddy از نسخه 2.8 از ARI پشتیبانی می‌کند و در غیر این صورت پس از دو سوم طول عمر گواهی تمدید می‌کند. گواهی Wildcard فعال حدود ۵۰ روز از یک گواهی ۹۰ روزه را سپری کرده بود و هنوز تمدید نشده بود؛ رفتاری که با همان قانون دو سوم قابل توضیح است. برای آزمون واقعی، یک سایت آزمایشی موقت به محیط Staging اشاره داده شد و در تلاش دوم، گواهی ۶۴ روزه‌ای با تاریخ صدور ۲۵ اکتبر و انقضای ۲۸ دسامبر دریافت شد.
Proxmox VE: کلاینت ACME داخلی
Proxmox VE کلاینت ACME داخلی دارد و افزونه‌های DNS آن بر پایه acme.sh هستند، بنابراین Cloudflare از ابتدا پشتیبانی می‌شود. با ثبت حساب Staging و Production و افزودن افزونه Cloudflare با تأخیر اعتبارسنجی ۳۰ ثانیه، یک گواهی Staging با عمر ۶۴ روز صادر شد. سپس در محیط Production یک گواهی معتبر ۹۰ روزه با انقضای ۲۳ ژانویه دریافت شد. سرویس روزانه pve-daily-update گواهی را زمانی که ۳۰ روز تا انقضا باقی مانده باشد تمدید می‌کند؛ بنابراین نخستین گواهی ۶۴ روزه Production در اواخر فوریه صادر خواهد شد.
Synology DSM: acme.sh و یک تنظیم دستی
در DSM 7.3.2، گزینه داخلی Let’s Encrypt از چالش DNS پشتیبانی نمی‌کند. به همین دلیل نویسنده acme.sh را روی خود NAS نصب کرده و از deploy hook سینولوژی استفاده کرده است؛ روشی که می‌تواند برای هر استقرار یک حساب مدیریتی موقت بسازد و پس از پایان کار آن را حذف کند. در این بخش نیز از چالش DNS-01 استفاده شده است. گواهی Staging در این بخش نیز ۶۴ روزه بود و لاگ ARI نشان داد که Let’s Encrypt تمدید را حدود روز ۴۲ پیشنهاد داده است. چون گواهی نام جداگانه‌ای داشت، به‌صورت خودکار جایگزین گواهی پیش‌فرض DSM نشد و یک بار به‌صورت دستی تنظیم شد. پس از آن، یک وظیفه روزانه در Task Scheduler DSM مسئول تمدید است.
مشکلاتی که ربطی به گواهی نداشتند
بیشتر زمان صرف‌شده در این آزمایش مربوط به خود گواهی‌ها نبود، بلکه به تنظیمات پیرامون آن‌ها مربوط می‌شد. برای نمونه، نام میزبان جدید Proxmox هنگام پرس‌وجوی مستقیم از Technitium DNS درست پاسخ می‌داد، اما رایانه رومیزی پاسخ را از سرورهای نام عمومی Cloudflare می‌گرفت؛ زیرا آداپتور شبکه به روتر eero اشاره می‌کرد و eero درخواست‌های دامنه آزمایشگاه را به Technitium نمی‌فرستاد. همچنین DSM در ابتدا گواهی Wildcard مربوط به Caddy را نشان می‌داد، چون هنوز از آدرس پروکسی‌شده قدیمی استفاده می‌شد؛ بررسی مستقیم با OpenSSL نشان داد که NAS هنوز گواهی خودامضای Synology را سرو می‌کند. در Chrome نیز هشدار قدیمی خطای گواهی تا پایان نشست باقی مانده بود و با راه‌اندازی مجدد کامل مرورگر برطرف شد.
پایش تمدید: automation بدون هشدار کافی نیست
نویسنده برای جلوگیری از شکست خاموش در تمدید خودکار، اسکریپتی نوشته است که هر صبح روی کانتینر Caddy اجرا می‌شود و هر سه گواهی را بررسی می‌کند. اگر عمر هر گواهی کمتر از ۱۴ روز شود، اگر گواهی هنوز از محیط Staging باشد یا اگر اعتبارسنجی آن شکست بخورد، اسکریپت از طریق webhook به Home Assistant اطلاع می‌دهد. در این تنظیمات، هر کلاینت با ۲۱ تا ۳۵ روز باقی‌مانده روی یک گواهی ۶۴ روزه تمدید می‌کند؛ بنابراین عمر کمتر از ۱۴ روز یعنی دست‌کم یک هفته تلاش ناموفق برای تمدید. اجرای نخست، عمر ۳۹، ۸۹ و ۸۹ روز را گزارش کرد و یک آزمون اجباری نیز اعلان را در Home Assistant ثبت کرد.
جمع‌بندی این تجربه روشن است: کاهش عمر گواهی‌های Let’s Encrypt به ۶۴ و سپس ۴۵ روز، به‌خودی‌خود فاجعه نیست، اما هر تنظیم ثابت و هر تمدید خودکار بدون پایش می‌تواند به انقضای ناخواسته گواهی منجر شود. استفاده از ARI، تنظیم تمدید بر پایه دو سوم طول عمر و افزودن هشدار برای تمدیدهای ناموفق، سه اقدام کلیدی برای عبور بی‌دردسر از این تغییر است.