اگر برای اولین بار با یک محیط Homelab یا حتی یک vCenter عملیاتی سروکار داشته باشید، شاید در نگاه اول به موضوع انقضای گواهیها توجه نکنید. این دقیقاً همان مشکلی است که معمولاً تا زمان بروز خطا خودش را نشان نمیدهد. در موردی که من بررسی کردم، اولین نشانه مشکل یک خطای عمومی و آزاردهنده بود:
HTTP Status 500 – Internal Server Error
این خطا در ظاهر اطلاعات زیادی نمیدهد، اما در محیط vCenter معمولاً میتواند نشانهای از مشکل در سرویسها، trust chain، یا انقضای یکی از certificateها باشد. در چنین شرایطی، اولین کار این است که وضعیت گواهیهای نصبشده را بررسی کنیم.
چگونه وضعیت certificateهای vCenter را بررسی کنیم؟
برای مشاهده وضعیت certificate storeها میتوان از دستور زیر استفاده کرد:
for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo "[*] Store :" $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After";done;
این دستور تمام storeهای گواهی را بررسی میکند و برای هر کدام، Alias و تاریخ Not After را نمایش میدهد؛ یعنی همان تاریخی که پس از آن certificate دیگر معتبر نیست.
در بررسی انجامشده مشخص شد که گواهی Machine SSL منقضی شده بود. این دقیقاً همان certificateای است که برای ارتباطات اصلی سرویسهای vCenter اهمیت زیادی دارد و انقضای آن میتواند باعث اختلال در UI و سرویسهای وابسته شود.
راهحل اولیه: جایگزینی certificate منقضیشده
برای تعویض گواهی منقضیشده، ابزار رسمی VMware به نام certificate-manager استفاده میشود:
/usr/lib/vmware-vmca/bin/certificate-manager
از آنجا که در این سناریو فقط نیاز به تعویض Machine SSL certificate وجود داشت، گزینه 3 انتخاب شد.
در این مثال، certificate از نوع self-signed بود؛ بنابراین بیشتر مقادیر پیشفرض قابل قبول بودند و فقط دو مقدار زیر بهصورت دستی وارد شدند:
- Hostname
- VMCA Name
هر دو مقدار با نام vCenter تکمیل شدند.
پس از تکمیل اطلاعات، کافی است با گزینه Y فرآیند را ادامه دهید.
مشکل در مرحله راهاندازی مجدد سرویسها
متأسفانه پس از پایان فرآیند تعویض certificate، در مرحله راهاندازی مجدد سرویسها خطا رخ داد.
در چنین مواقعی معمولاً باید لاگهای مرتبط بررسی شوند تا مشخص شود مشکل از کجاست.
لاگهای بررسیشده:
less /var/log/vmware/vmcad/certificate-manager.log
و همچنین:
less /storage/log/vmware/cloudvm/service-control.log
با وجود بررسی این دو فایل، اطلاعات خیلی مفیدی برای تشخیص ریشه مشکل به دست نیامد.
سپس تلاش شد سرویسها بهصورت دستی دوباره بالا بیایند:
service-control --start --all
اما این روش هم نتیجهای نداشت.
بازنشانی کامل certificateها
در مرحله بعد، تصمیم گرفته شد فرآیند Reset of all Certificates انجام شود.
برای این کار دوباره certificate manager اجرا شد، اما این بار گزینه 8 انتخاب گردید.
پس از انجام این مرحله و حتی بعد از reboot، وضعیت هنوز مطلوب نبود. بررسی همه سرویسها نشان داد که سرویس vsphere-ui بالا نیامده است:
service-control --status --all
در این نقطه مشخص شد که فقط تعویض certificate کافی نبوده و احتمالاً مشکل به trust relationship بین سرویسها یا ناسازگاری SSL برمیگردد.
استفاده از ابزار lsdoctor برای رفع trust mismatch
VMware ابزاری به نام lsdoctor ارائه کرده است که برای رفع مشکلات trust و certificate mismatch بسیار کاربردی است.
این ابزار در مقاله/KB مربوطه با شناسه kb80469 معرفی شده است.
مراحل استفاده به این شکل است:
- ابزار را روی vCenter آپلود کنید.
- آن را unzip کنید.
- سپس دستور زیر را اجرا نمایید:
python lsdoctor.py -l
خروجی این دستور نشان داد که چند مورد SSL trust mismatch وجود دارد.
در ادامه ابزار پیشنهاد کرد که برای اصلاح این موارد، دستور زیر اجرا شود:
python lsdoctor.py -t
پس از اجرای این فرمان، مشکل trust برطرف شد و سرویسها توانستند مجدداً بهدرستی بالا بیایند.
بیشتر بخوانید: VMware ESXi و نقش آن در مجازی سازی سرور
نتیجه نهایی
پس از رفع خطا و راهاندازی مجدد سرویسها، دسترسی به vCenter دوباره برقرار شد و محیط به حالت عادی بازگشت.
این تجربه یک نکته مهم را یادآوری میکند:
در vCenter، انقضای certificate فقط یک هشدار ساده نیست؛
در بسیاری از موارد میتواند به اختلال کامل در سرویسها و UI منجر شود.
بنابراین، پایش منظم وضعیت certificateها، بررسی تاریخ انقضا، و آمادگی برای استفاده از ابزارهای رسمی VMware، بخش مهمی از نگهداری صحیح vCenter است.