وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای Too Many Certificates در Let’s Encrypt؛ چطور محدودیت صدور SSL را رفع کنیم؟

تشخیص محدودیت صدور SSL، خواندن Retry-After، آزمایش staging و جلوگیری از درخواست‌های تکراری گواهی.

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای Too Many Certificates در Let’s Encrypt؛ چطور محدودیت صدور SSL را رفع کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
هنگام صدور یا تمدید گواهی HTTPS پیامی مانند too many certificates یا rate limit exceeded می‌بینید. این پیام یعنی یکی از محدودیت‌های مرجع صدور برای درخواست شما فعال شده است. علت می‌تواند تلاش‌های تکراری، صدورهای متعدد برای مجموعه نام یکسان یا شکست‌های پی‌درپی در تأیید دامنه باشد.
اولین کار این است که دکمه صدور را پشت سر هم نزنید. باید نوع محدودیت و زمان مجاز تلاش دوباره را از خود خطا بخوانیم و در این فاصله علت اصلی را برطرف کنیم. حذف گواهی قبلی یا نصب مجدد تصادفی ابزار صدور لزوماً محدودیت را پاک نمی‌کند.

قدم اول: متن کامل خطا و زمان را پیدا کنید

در پنل هاست، صفحه SSL یا گزارش ابزار صدور را باز کنید. نام بخش و مرجع صادرکننده در سرویس‌های مختلف فرق دارد؛ همه گواهی‌های خودکار لزوماً از Let's Encrypt نیستند. اگر Let's Encrypt در خطا ذکر شده است، عبارت مربوط به محدودیت، نام‌های درخواست‌شده و زمان خطا را یادداشت کنید.
پیام ممکن است به یکی از این موارد اشاره کند:
  • تعداد گواهی برای مجموعه مشخصی از نام‌ها؛ مثلاً دامنه اصلی و www با هم.
  • تعداد صدور برای دامنه ثبت‌شده یا تعداد سفارش‌های یک حساب.
  • شکست‌های پی‌درپی تأیید مالکیت برای یک نام مشخص.
  • محدودیت تعداد درخواست به یک بخش از سرویس یا محدودیت دیگری که در متن خطا نام برده شده است.
همه این محدودیت‌ها یکسان نیستند و بازه و شیوه محاسبه آن‌ها می‌تواند تغییر کند. به‌جای تکیه بر یک عدد قدیمی در مقاله‌های اینترنتی، جدول رسمی محدودیت‌های Let's Encrypt را برای نوع خطای خود ببینید. گزارش را بدون کلید خصوصی، رمز و اطلاعات حساب با مدیر سرویس به اشتراک بگذارید.
اگر در پیام عبارت retry after یا سرآیند Retry-After وجود دارد، همان زمان را ثبت کنید. ممکن است زمان اعلام‌شده بر اساس UTC باشد؛ قبل از مقایسه با ساعت محلی، منطقه زمانی را در نظر بگیرید. اگر چند محدودیت هم‌زمان اعمال شده باشند، نتیجه نهایی به همه آن‌ها وابسته است.

قدم دوم: ببینید گواهی فعلی واقعاً چه وضعی دارد

سایت را با HTTPS باز و جزئیات گواهی را در مرورگر ببینید: نام‌های پوشش‌داده‌شده، مرجع و تاریخ انقضا را یادداشت کنید. اگر از CDN استفاده می‌کنید، گواهی دیده‌شده در مرورگر ممکن است گواهی لبه CDN باشد، نه گواهی نصب‌شده روی سرور اصلی. وضعیت هر دو مسیر باید جداگانه مشخص شود.
اگر گواهی فعلی هنوز معتبر است، آن را بی‌دلیل حذف یا با گواهی آزمایشی جایگزین نکنید. اگر منقضی شده یا نام درست را پوشش نمی‌دهد، از میزبان درباره روش معتبر و سازگار برای حفظ یا بازیابی HTTPS بپرسید. خاموش‌کردن تأیید گواهی در مرورگر یا برنامه‌ها مشکل را حل نمی‌کند.

قدم سوم: علت درخواست‌های تکراری را پیدا کنید

گزارش صدور را به ترتیب زمان بخوانید. اگر هر چند دقیقه یک تلاش ناموفق ثبت شده، ممکن است یک کار زمان‌بندی، افزونه یا چند کنترل‌پنل مستقل برای همان نام درخواست می‌فرستند. مدیر باید منبع تلاش تکراری را شناسایی و طبق برنامه کنترل کند؛ متوقف‌کردن کل سیستم تمدید همه سایت‌ها بدون شناخت اثر آن مناسب نیست.
اگر علت اصلی شکست تأیید مالکیت است، متن خطای قبل از محدودیت را پیدا کنید. در روش HTTP-01 ممکن است فایل چالش از بیرون درست قابل دسترس نبوده باشد؛ در روش DNS-01 ممکن است رکورد TXT اشتباه، در منطقه نادرست یا هنوز کش‌شده باشد. مشکل CAA، نام دامنه یا فایروال هم ممکن است مسیر دیگری داشته باشد. راهنمای خطای Unauthorized در Let's Encrypt مراحل بررسی HTTP-01 را توضیح می‌دهد.
اگر تعداد زیادی گواهی موفق برای همان نام‌ها صادر شده، ببینید آیا اسکریپت به‌جای استفاده از گواهی موجود، هر بار درخواست تازه می‌سازد یا چند ماشین یک کار مشترک را تکرار می‌کنند. فهرست نام‌های گواهی و حساب‌های صدور را با مسئول هر سرویس تطبیق دهید. افزودن یک نام تصادفی یا ساخت حساب تازه برای دورزدن مشکل، ممکن است به محدودیت دیگری بخورد و علت را پنهان کند.

قدم چهارم: آزمایش را با محیط آزمایشی انجام دهید

اگر ابزار شما از محیط staging پشتیبانی می‌کند، مدیر می‌تواند در یک سایت یا محیط آزمایشی جدا مسیر درخواست و تأیید مالکیت را با آن امتحان کند. محیط آزمایشی برای عیب‌یابی مناسب است و مصرف محدودیت تولید را کاهش می‌دهد، اما گواهی آزمایشی توسط مرورگرهای معمول قابل اعتماد نیست. آن را به‌جای گواهی معتبر سایت عمومی نصب نکنید.
برای تنظیم staging، راهنمای همان ابزار یا کنترل‌پنل را بخوانید؛ نام گزینه در Certbot، کنترل‌پنل‌ها و سرویس‌ها متفاوت است. پس از موفقیت آزمایش، تنظیم محیط تولید و مسیر نصب گواهی واقعی را بررسی کنید. توضیح رسمی محیط staging تفاوت اعتماد و هدف آزمون را شرح می‌دهد.

چه زمانی دوباره درخواست بدهیم؟

پس از رفع علت، تا زمان اعلام‌شده در خطا صبر کنید و طبق روش پنل یک تلاش کنترل‌شده انجام دهید. اگر پیام محدودیت دیگری ظاهر شد، متن همان پیام جدید را بخوانید؛ برگشتن اولین ظرفیت الزاماً به معنی رفع همه محدودیت‌ها نیست. صدور موفق باید با نصب درست گواهی و آزمایش نام‌های موردنیاز دنبال شود.
در مرورگر یا ابزار معتبر، نام دامنه، تاریخ، زنجیره و نتیجه اتصال را ببینید. اگر گواهی صادر شده ولی سایت همچنان هشدار دارد، ممکن است گواهی روی وب‌سرور اشتباه نصب شده یا CDN و سرور اصلی تنظیم متفاوتی داشته باشند. در این حالت تکرار صدور اولین قدم مناسب نیست.
برای دامنه‌هایی که از خدمات ثبت دامنه نت‌آرام استفاده می‌کنند، محل DNS فعال و هاست صادرکننده را جدا مشخص کنید. پشتیبانی برای بررسی به نام دامنه، متن کامل خطا و زمان تلاش نیاز دارد، نه رمز پنل یا کلید خصوصی.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام