Certbot چه کاری را خودکار می‌کند؟
Certbot ابزار متن‌باز دریافت و مدیریت گواهی با پروتکل ACME است که پروژه آن با بنیاد مرزهای الکترونیکی شناخته می‌شود. کاربرد رایج آن دریافت گواهی از مرجع صادرکننده و هماهنگ کردن تمدید برای سرویس وب است. این ابزار خود مرجع صدور گواهی نیست؛ با مرجع ارتباط برقرار می‌کند، فرایند اثبات کنترل دامنه را انجام می‌دهد و بسته به افزونه انتخاب‌شده می‌تواند در نصب گواهی روی وب‌سرور نیز کمک کند.
مرز این مسئولیت اهمیت دارد. موفقیت Certbot در دریافت یک گواهی به معنای امن شدن تمام برنامه وب نیست. آسیب‌پذیری کد، احراز هویت کاربران، مجوز دسترسی و محتوای مختلط همچنان نیازمند بررسی هستند. از سوی دیگر، دریافت گواهی بدون برنامه تمدید و بارگذاری مجدد نیز پایان کار نیست. ارزش اصلی ابزار در تبدیل یک کار تکرارشونده به فرایندی قابل آزمون است که پیش از انقضا گواهی تازه را به سرویس مصرف‌کننده می‌رساند.
فرض کنید یک سازمان وب‌سایت اصلی، رابط برنامه‌نویسی و پنل پشتیبانی دارد. هر نام ممکن است روی میزبان، پراکسی یا متوازن‌کننده متفاوتی پایان یابد. پیش از اجرای فرمان باید مشخص شود اتصال TLS کجا خاتمه پیدا می‌کند و کدام ماشین باید گواهی را دریافت کند. نصب Certbot روی سرور برنامه‌ای که پشت یک پراکسی قرار دارد الزاماً به معنای تغییر گواهی قابل مشاهده برای بازدیدکننده نیست.
انتخاب روش نصب و افزونه
صفحه رسمی راهنمای نصب، انتخاب متناسب با سیستم‌عامل و وب‌سرور را ارائه می‌کند. روش نصب را از همان مسیر انتخاب و نسخه مورد استفاده را ثبت کنید. ترکیب بی‌برنامه چند روش نصب ممکن است باعث شود فرمان تعاملی یک باینری را اجرا کند و وظیفه زمان‌بندی‌شده باینری دیگری را. در زمان عیب‌یابی، مسیر واقعی فرمان، نسخه و افزونه‌های در دسترس را بررسی کنید؛ وجود نام Certbot در خروجی نصب برای اثبات یکسان بودن محیط کافی نیست.
افزونه‌ها دو نقش مهم دارند: احراز کنترل دامنه و نصب گواهی. بعضی افزونه‌ها هر دو را انجام می‌دهند و بعضی فقط گواهی را دریافت می‌کنند. برای مثال روش webroot فایل چالش را در ریشه وب موجود می‌نویسد، اما مسئولیت نصب گواهی در سرویس مقصد جدا باقی می‌ماند. انتخاب این روش برای تیمی که نمی‌خواهد ابزار تنظیمات وب‌سرور را تغییر دهد قابل بررسی است، به شرط آنکه مسئولیت مرحله بعد فراموش نشود.
افزونه‌های Apache و Nginx می‌توانند مسیر دریافت و نصب را برای محیط‌های پشتیبانی‌شده ساده کنند. پیش از اجرای آن‌ها از تنظیمات وب‌سرور نسخه پشتیبان بگیرید و ساختار میزبان‌های مجازی را بشناسید. در پیکربندی پیچیده، محل TLS و نام دامنه ممکن است با تشخیص ساده ابزار یکسان نباشد. پس از اجرا باید تنظیمات و رفتار واقعی سرویس بررسی شود، نه اینکه صرفاً پیام موفقیت فرمان پذیرفته شود.
روش webroot در سرویس موجود
در روش webroot وب‌سرور موجود روشن می‌ماند و Certbot فایل لازم برای چالش را زیر مسیر مشخص می‌سازد. مرجع صادرکننده باید بتواند آن فایل را از نشانی عمومی مربوط به دامنه دریافت کند. بنابراین مسیر محلی و مسیر منتشرشده وب باید واقعاً به یک محل اشاره کنند. در پروژه‌ای با چند ریشه وب، انتخاب مسیر مربوط به دامنه دیگر می‌تواند باعث شکست اعتبارسنجی شود.
نمونه زیر برای دامنه تحت کنترل اجراکننده و مسیر وب از قبل آماده‌شده است. نام نمونه و مسیر باید با محیط واقعی جایگزین شوند؛ این فرمان به تنهایی گواهی را در تمام سرویس‌ها نصب نمی‌کند.
certbot certonly --webroot -w /var/www/example -d example.com
پیش از درخواست واقعی، دسترسی به یک فایل آزمایشی در مسیر چالش را از بیرون شبکه بررسی کنید. قوانین بازنویسی، احراز هویت سراسری یا مسدود کردن مسیرهای دارای نقطه ممکن است پاسخ چالش را تغییر دهند. پاسخ موفق صفحه اصلی کافی نیست؛ همان مسیر ویژه باید به محتوای مورد انتظار برسد. اگر چند گره پشت متوازن‌کننده هستند، درخواست می‌تواند به گره‌ای برسد که فایل روی آن وجود ندارد.
در چنین خوشه‌ای، یا مسیر چالش باید میان گره‌ها هماهنگ باشد یا مسیریابی آن به گره مسئول به صورت روشن انجام شود. تغییر موقت مسیر هنگام صدور نخست، اگر برای تمدید خودکار باقی نماند، بعداً شکست ایجاد می‌کند. طراحی باید برای اجرای بدون حضور انسان نیز معتبر باشد. بهتر است همین شرایط در آزمون تمدید بررسی شود تا وابستگی پنهان به یک اقدام دستی آشکار شود.
روش standalone و مسئله درگاه
روش standalone وب‌سرور موقت خود را برای پاسخ دادن به چالش اجرا می‌کند. مستندات رسمی برای چالش وب این روش آزاد بودن درگاه لازم را مطرح می‌کنند. اگر Nginx یا سرویس دیگری از قبل همان درگاه را گرفته باشد، اجرای دوم نمی‌تواند بدون هماهنگی روی آن گوش کند. خاموش کردن سرویس تولید فقط برای گرفتن گواهی ممکن است وقفه ایجاد کند و باید در طراحی انتخاب روش لحاظ شود.
در محیطی که وب‌سرور ندارد یا دریافت گواهی برای سرویس دیگری انجام می‌شود، این روش می‌تواند ساده باشد. با این حال مسیر دسترسی شبکه، فایروال و ترجمه نشانی همچنان باید اجازه اعتبارسنجی بدهند. موفقیت اتصال محلی به درگاه، دسترسی مرجع صادرکننده از اینترنت را اثبات نمی‌کند. اگر سازمان نمی‌خواهد چنین مسیر ورودی داشته باشد، روش مبتنی بر DNS را متناسب با امکانات بررسی کند.
چالش DNS و گواهی wildcard
افزونه‌های DNS با تغییر رکورد مربوط به چالش کنترل دامنه را اثبات می‌کنند. مستندات Certbot می‌گوید دریافت گواهی wildcard از Let's Encrypt به اعتبارسنجی DNS نیاز دارد. این روش می‌تواند برای سرویس‌هایی که از اینترنت قابل دسترسی مستقیم نیستند مناسب باشد، اما مسئولیت تازه‌ای ایجاد می‌کند: اعتبارنامه دسترسی به سامانه مدیریت DNS باید محافظت شود و به محدوده لازم محدود بماند.
فایل اعتبارنامه DNS را در مخزن کد یا تصویر عمومی کانتینر قرار ندهید. مجوز فایل و حساب اجرایی باید طوری باشد که فقط فرایند مجاز بتواند آن را بخواند. در صورتی که ارائه‌دهنده امکان محدود کردن توکن به یک منطقه یا نوع عملیات را دارد، از همان محدودیت استفاده کنید. کسی که به این اعتبارنامه دست پیدا کند ممکن است فراتر از تمدید گواهی بر نام‌های سازمان اثر بگذارد.
انتشار تغییر DNS ممکن است فوری نباشد. باید پاسخ سرورهای معتبر و دید بیرونی را بررسی کرد، نه فقط حافظه نهان رایانه مدیر را. رکورد قدیمی، اشتباه در نام کامل و تفاوت منطقه اصلی با زیرمنطقه واگذارشده از مواردی هستند که ارزش بررسی دارند. مدت انتظار افزونه را مطابق مستند همان ارائه‌دهنده تنظیم کنید؛ عددی که برای یک سامانه جواب داده الزاماً برای دیگری مناسب نیست.
روش دستی و محدودیت تمدید
روش manual برای دنبال کردن گام‌های اعتبارسنجی به صورت دستی وجود دارد، اما مستندات رسمی هشدار می‌دهد گواهی‌های دریافت‌شده به این شیوه بدون خودکار کردن مراحل لازم تمدید خودکار ندارند. اگر قرار است هر بار فردی رکورد بسازد یا فایل کپی کند، وجود یک وظیفه زمان‌بندی‌شده به تنهایی این وابستگی را حذف نمی‌کند. روش دستی را با یک فرایند کاملاً خودکار اشتباه نگیرید.
برای تبدیل این مسیر به خودکارسازی باید hook احراز مناسب و پاک‌سازی آن طراحی و آزمایش شود. این اسکریپت‌ها ممکن است به اعتبارنامه حساس دسترسی داشته باشند؛ ورودی، مجوز اجرا و رفتار شکست آن‌ها اهمیت دارد. برای کاربرد معمول، افزونه رسمی مناسب می‌تواند مسئولیت کمتری نسبت به اسکریپت سفارشی ایجاد کند. انتخاب نهایی باید با امکانات ارائه‌دهنده و توان نگهداری تیم هماهنگ باشد.
آزمون تمدید و زمان‌بندی
بعد از دریافت اولیه، فرمان آزمون تمدید یکی از بررسی‌های ضروری است. این آزمون کمک می‌کند مشخص شود پارامترهای ثبت‌شده و مسیر اعتبارسنجی هنوز کار می‌کنند. بهتر است با همان حساب و شرایطی اجرا شود که وظیفه خودکار خواهد داشت. موفقیت اجرای تعاملی مدیر، دسترسی فایل یا متغیر محیطی لازم برای اجرای پس‌زمینه را تضمین نمی‌کند.
certbot certificates
certbot renew --dry-run
فرمان نخست برای مشاهده گواهی‌های مدیریت‌شده و نام آن‌ها مفید است. فرمان دوم آزمون تمدید است و جای بررسی گواهی ارائه‌شده واقعی در سرویس را نمی‌گیرد. بیشتر روش‌های نصب، زمان‌بندی را آماده می‌کنند؛ پیش از ساخت وظیفه جدید راهنمای نصب و timer یا cron موجود را بررسی کنید. داشتن چند اجرای پراکنده با تنظیمات متفاوت، فهمیدن علت شکست را دشوارتر می‌کند.
برای پایش، زمان باقی‌مانده گواهی قابل مشاهده از بیرون را نیز اندازه بگیرید. فقط بررسی کد خروج اجرای شبانه کافی نیست، زیرا ممکن است هنوز موعد تمدید نرسیده باشد یا گواهی تازه نصب نشده باشد. هشدار باید پیش از انقضا فرصت رسیدگی بدهد و مسئول مشخص داشته باشد. در محیط چنددامنه، یک هشدار عمومی نباید پنهان کند که کدام نام و کدام سرویس به اقدام نیاز دارد.
تفاوت تمدید با بارگذاری مجدد
بعضی سرویس‌ها پس از تغییر فایل گواهی همچنان نسخه قبلی را در حافظه نگه می‌دارند. در این حالت Certbot کار دریافت را انجام داده، ولی بازدیدکننده گواهی تازه را نمی‌بیند. باید مرحله استقرار یا بارگذاری مجدد با رفتار واقعی سرویس هماهنگ شود. قبل از reload نیز اعتبار پیکربندی سرویس را بررسی کنید تا تغییر مرتبط با گواهی به قطعی ناشی از فایل تنظیمات معیوب تبدیل نشود.
مستندات میان hook پیش از تلاش، پس از تلاش و deploy hook تمایز می‌گذارد. اگر عملی فقط پس از تمدید موفق باید اجرا شود، deploy hook انتخاب مرتبط است؛ اجرای آن را نباید با هر اجرای فرمان renew یکسان فرض کرد. اسکریپت باید مسیر گواهی درست را استفاده کند و خطا را گزارش دهد. از قرار دادن فرمان بسیار گسترده مدیریتی در hook بدون نیاز مشخص خودداری کنید.
در انتقال گواهی به ماشین دیگر، مسئله حفاظت از کلید خصوصی هم اضافه می‌شود. ارتباط انتقال، مجوز مقصد و روش جایگزینی فایل‌ها باید امن و هماهنگ باشند. استفاده از مسیرهای مدیریت‌شده Certbot را با درک رابطه فایل‌ها و پیوندهای آن انجام دهید. کپی دستی پراکنده می‌تواند باعث شود سرویس ماه‌ها از نسخه قدیمی استفاده کند، در حالی که پوشه اصلی مرتب تمدید شده است.
تغییر پیکربندی و جلوگیری از درخواست تکراری
وقتی مسیر وب یا روش احراز تغییر می‌کند، تنظیمات تمدید نیز باید به‌روز شوند. مستندات برای نسخه‌های جدید فرمان reconfigure را معرفی می‌کند که گزینه‌های تازه را با آزمون بررسی و پس از موفقیت ثبت می‌کند. ابتدا نام گواهی را از خروجی رسمی پیدا کنید و راهنمای نسخه نصب‌شده را بخوانید. ویرایش دستی فایل‌های تمدید بدون شناخت ساختار ممکن است روند خودکار را خراب کند.
برای اشکال‌زدایی از آزمون و محیط مناسب استفاده کنید و با درخواست‌های پی‌درپی واقعی تلاش نکنید خطا را پیدا کنید. مرجع صادرکننده محدودیت‌های صدور دارد که مقدار و شرایط آن باید از مستند جاری همان مرجع بررسی شود. هیچ عدد ثابتی در این راهنما جایگزین آن سیاست نیست. وقتی مشکل مسیریابی یا DNS است، دریافت بارها گواهی تازه راه‌حل اصلی محسوب نمی‌شود.
خطاهای شبکه و معیار پایان کار
در شکست اعتبارسنجی، نام دامنه و رکوردهای آن، مسیر عمومی، پاسخ چالش و گزارش مرجع را مرحله‌به‌مرحله بررسی کنید. اگر دامنه هم رکورد IPv4 و هم IPv6 دارد، مسیر خراب یکی از آن‌ها می‌تواند بررسی را پیچیده کند. پراکسی یا شبکه توزیع محتوا نیز ممکن است پاسخ دیگری ارائه دهد. آزمون از داخل همان سرور تنها بخشی از مسیر را می‌بیند.
در خطای TLS پس از صدور، نام گواهی، زنجیره و گواهی ارائه‌شده سرویس را بررسی کنید. خطای مجوز خواندن کلید خصوصی را با باز کردن مجوز فایل برای همه کاربران رفع نکنید؛ حساب سرویس و گروه مناسب را مشخص کنید. برای گزارش عیب، متن خطای پاک‌شده کافی است و نباید کلید خصوصی در پیام یا سامانه پشتیبانی قرار گیرد.
پایان موفق استقرار Certbot زمانی است که دریافت مجاز، تمدید بدون تعامل، بارگذاری گواهی جدید و هشدار پیش از انقضا همگی آزمایش شده باشند. یک دامنه آزمایشی با مسیر مشابه تولید می‌تواند برای تمرین تغییرات مفید باشد. مسئولیت مالک دامنه، مدیر DNS و مدیر سرویس را نیز ثبت کنید تا هنگام جابه‌جایی زیرساخت، فرایند تمدید بدون صاحب باقی نماند.
