خطای گواهی وب در Access Server: بسته CA خالی

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

سه کلید واقعاً به چه چیزی اشاره می‌کنند

مجموعه گواهی وب سفارشی با cs.cert، cs.priv_key و cs.ca_bundle توصیف می‌شود. هر یک مسیری به یک فایل نگه می‌دارد و سرویس وب هر سه را با هم مصرف می‌کند. گواهی با کلید اشتباه، یا فایل زنجیره‌ای که در واقع گواهی برگ است، مانند مقدار خالی شکست می‌خورد: شنونده نمی‌تواند زنجیره‌ای بسازد که مرورگر بپذیرد.

این کلیدها به رابط وب Admin و Client تعلق دارند. آن‌ها از PKI که گواهی به کلاینت‌های وی‌پی‌ان صادر می‌کند جدا هستند، پس جایگزینی نیازی به دست زدن به نمایه‌های کلاینت، کلید سرور یا مرجع گواهی ندارد. تلقی یک نقص TLS وب به عنوان دلیل بازسازی کل PKI گران‌ترین اشتباه ممکن در اینجا است.

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

چرا فایلی که وجود دارد باز هم تجزیه نمی‌شود

تجزیه‌گر بلوک‌های برچسب‌دار داخل فایل را می‌خواند، نه نام فایل را. یک .crt که کلید خصوصی دارد، زنجیره‌ای که به صورت یک بلوک به هم پیوسته نوشته شده جایی که یک گواهی انتظار می‌رفت، یا فایلی که خط آخرش بریده ذخیره شده، همه رد می‌شوند. RFC 7468 آن برچسب‌های خوانا را تعریف می‌کند چون تنها چیزی هستند که به خواننده می‌گوید چه نوع شیئی در ادامه می‌آید.

اشیاء را بررسی کنید، نه پسوندها را. روی میزبان Linux، openssl x509 -noout -subject -issuer -in server.pem و openssl pkey -noout -check -in key.pem به دو پرسش مهم پاسخ می‌دهند و مقایسه مدول یا کلید عمومی هر دو ثابت می‌کند که به هم تعلق دارند. خروجی کلید خصوصی را از تیکت‌ها و گزارش‌های گفتگو دور نگه دارید؛ بررسی به اثر انگشت نیاز دارد، نه به کلید.

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

عمداً به گزینه پشتیبان برگردید

CLI در Access Server یک بررسی اعتبارسنجی دارد که سه مسیر را به عنوان آرگومان می‌گیرد و گزارش می‌کند که مجموعه قابل استفاده است یا نه. مسیرهای زیر نمونه‌اند؛ آن‌ها را با مکان‌های محافظت‌شده روی میزبان جایگزین کنید:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

نامی را که کاربران واقعاً تایپ می‌کنند بررسی کنید

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

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

پاک کردن کل پایگاه داده پیکربندی تعمیر گواهی نیست. همان سه کلید را هدف بگیرید، اعمال کنید و تأیید کنید که رابط وب پاسخ می‌دهد. فایل‌های خودامضا در پوشه web-ssl منبع جایگزین هستند، نه فضای کار: بازنویسی یا بازتولید آن‌ها می‌تواند تنها ماده کارآمد را حذف کند.

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

بازیابی تنها با یک ورود موفق کامل می‌شود

بازیابی با ظاهر شدن یک شنونده TCP تمام نمی‌شود. نام DNS، هویت گواهی و زنجیره آن نام را اعتبارسنجی کنید، سپس هر دو رابط وب Admin و Client را بارگذاری و یک ورود را کامل کنید. بررسی پورت هیچ‌یک از این‌ها را اثبات نمی‌کند.

Access Server 3.1 و بالاتر می‌توانند گواهی‌های وب متفاوت برای هر نام میزبان SNI ارائه دهند. اگر این پیکربندی شده باشد، کلیدهای پیش‌فرض و ورودی‌های مخصوص نام مجموعه‌های جداگانه‌اند و آزمایش با نشانی IP به‌راحتی گواهی متفاوتی از آنچه کاربران می‌گیرند نشان می‌دهد. مجموعه نام ناموفق را تعمیر و بررسی کنید و پیش از بستن حادثه آزمون ورود را تکرار کنید.