SoftEther ServerCertSet: وارد کردن زنجیره تازه‌شده با vpncmd

Certbot تمدید موفق را گزارش می‌دهد، فایل‌های روی دیسک تاریخ‌های تازه دارند، و کلاینت‌ها هنوز با هویت قدیمی روبه‌رو می‌شوند. SoftEther گواهی SSL سرور خود را در پیکربندی سطح سرور خود نگه می‌دارد، پس فایل تازه روی دیسک تا زمانی که برگ و کلیدش وارد نشوند چیزی را تغییر نمی‌دهد. دنباله زیر یک ورود دستی، یک پوسته که پس از هر تمدید اجرا می‌شود، و یک بررسی که می‌خواند شنونده در واقع چه ارائه می‌دهد را پوشش می‌دهد. هر گام شواهدی باقی می‌گذارد که می‌توانید پس از تمدید بعدی مقایسه کنید.

فایل تازه‌شده هویت سرور را تغییر نمی‌دهد

صدور و استقرار رویدادهای جداگانه‌ای با شیوه‌های شکست جداگانه‌اند. کلاینت ACME فایل‌ها را در پوشه دودمان می‌نویسد و موفقیت را ثبت می‌کند؛ SoftEther همچنان از گواهی‌ای استفاده می‌کند که آخرین بار در پیکربندی‌اش بارگذاری شده است. پس وضعیت خروج صفر فایل‌ها را توصیف می‌کند نه سرویس را، و این دو تا وقتی کسی نگاه نمی‌کند می‌توانند ناسازگار بمانند. ورود را گام استقرار و تمدید را ورودی آن بدانید.

این تمایز نیمه‌شکست گیج‌کننده را هم توضیح می‌دهد: گواهی قدیمی تا انقضایش کار می‌کند، پس در آغاز چیزی خراب به نظر نمی‌رسد. وقتی منقضی شود، همه کلاینت‌ها یک‌جا شکست می‌خورند، که شبیه قطعی است نه گام استقرار جاافتاده. بررسی هویت ارائه‌شده پس از هر تمدید آن غافلگیری را به مشاهده‌ای روزمره تبدیل می‌کند.

چالش مناسب شنونده را انتخاب کنید

گواهی باید میزبان مورد تأیید کلاینت‌ها را نام ببرد، پس از نام DNS عمومی استفاده کنید نه برچسب داخلی یا نشانی. HTTP-01 نیاز دارد چالش لحظه‌ای روی درگاه 80 پاسخ داده شود، که شنونده‌ای موقت است و هرگز دلیلی برای جابه‌جایی درگاه خود SoftEther نیست. DNS-01 کنترل را از طریق یک رکورد اثبات می‌کند و اصلاً به HTTP ورودی نیاز ندارد.

تمدید بدون نظارت یعنی یکپارچه‌سازی خودکار DNS با اعتبارنامه‌های محدود به یک ناحیه، نه رکورد TXT که هر دو ماه دستی تایپ شود. کارت عام نوع چالش را عوض می‌کند، نه نیاز به آن خودکارسازی را. این را پیش از وجود نخستین گواهی تصمیم بگیرید، چون تغییر نوع چالش در آینده یعنی دست‌زدن هم‌زمان به پیکربندی کلاینت و دیوار آتش.

تا اینجا هستید مصنوعات را مرتب نگه دارید. برگ و میانی‌ها هم به‌صورت فایل‌های جدا و هم به‌صورت یک فایل زنجیره ترکیبی می‌رسند، کلید خصوصی باز جدا است، و ورود به زنجیره با کلید منطبقش نیاز دارد نه گواهی عمومی به‌تنهایی.

زنجیره را در سطح سرور وارد کنید

از پیکربندی سرور نسخه پشتیبان بگیرید و پیش از دست‌زدن به گواهی تأیید کنید که هنوز به رابط مدیریت دسترسی دارید. به‌عنوان سرپرست سرور وصل شوید نه سرپرست Virtual Hub، چون گواهی به شیء سرور تعلق دارد. سپس زنجیره و کلید را با مسیر مطلق بارگذاری کنید، از فایل‌هایی که حسابی که فرمان را اجرا می‌کند می‌تواند بخواند. توجه کنید مسیرها مطلق‌اند چون فرمان آن‌ها را از پوشه کاری فرآیندی حل می‌کند که vpncmd را اجرا کرده است:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

خروجی فرمان را بخوانید به‌جای فرض موفقیت، و سپس زنجیره را دوباره بخوانید به‌جای اعتماد به فایلی که داده‌اید. مرز میان ساخت‌هایی که بسته کامل PEM را وارد می‌کنند و ساخت‌هایی که فقط نخستین گواهی را می‌گیرند در یک جا مستند نشده، پس بررسی همان چیزی است که آن را برای ساخت پیش روی شما روشن می‌کند. گواهی‌هایی را که شنونده ارائه می‌دهد بشمارید؛ برگی بدون میانی‌ها امضای واردکننده‌ای است که فقط بلوک اول را مصرف کرده است.

کلید واردشده را فقط برای حسابی که سرور را اجرا می‌کند خوانا نگه دارید، و گذرواژه مدیریت را بیرون از تاریخچه پوسته نگه دارید. برای این ورود نخست، گذرواژه را در اعلان تایپ کنید نه اینکه آن را به‌عنوان آرگومان فرمان بدهید. این دو عادت هیچ هزینه‌ای ندارند و رایج‌ترین راهی را که استقرار گواهی چیزی را که باید محافظت کند افشا می‌کند برمی‌دارند. این کار را پیش از نخستین ورود بکنید نه پس از آن.

استقرار را قلاب کنید، نه تمدید را

وقتی ورود دستی کار کرد، همان گام‌ها را در پوسته‌ای کوچک بگذارید و پس از تمدید موفق آن را از کلاینت ACME صدا بزنید. Certbot متغیرهای RENEWED_LINEAGE و RENEWED_DOMAINS را برای قلاب تنظیم می‌کند، پس پوسته می‌تواند روی یک گواهی در ماشینی که چند گواهی را مدیریت می‌کند عمل کند. بر اساس دودمان صافی کنید نه اینکه به هر تمدید روی میزبان واکنش نشان دهید. پوسته کد استقرار است که با اختیارات سرور اجرا می‌شود، پس آن را مانند هر اسکریپت دیگری در آن جایگاه بازبینی کنید.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

زنجیره ارائه‌شده را با فایل مقایسه کنید

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

سپس اتصال کلاینت تازه بسازید، چون نشست‌هایی که پیش از ورود برقرار شده‌اند در برابر هویت پیشین تأیید شده‌اند و چیزی درباره هویت تازه اثبات نمی‌کنند. اگر کلاینت‌ها برگ قدیمی را پین کنند، حتی وقتی زنجیره عمومی معتبر است به به‌روزرسانی هماهنگ نیاز دارند، و آن کار به همان دفترچه راهنمای تمدید تعلق دارد. یک پراکسی معکوس جلوی سرویس می‌تواند گواهی خوبی ارائه کند در حالی که شنونده VPN هنوز قدیمی را دارد، و از همین رو بررسی باید درگاهی را نام ببرد که کلاینت‌ها واقعاً به آن می‌رسند. اثر انگشت را کنار تاریخ تمدید ثبت کنید تا مقایسه بعدی یک بررسی باشد نه عملی از حافظه.