HTTPS به یک IP خصوصی: هویت گواهی یا نام میزبان؟
یک IP خصوصی میتواند هویت معتبر TLS باشد اگر گواهی چنین بگوید. بین SAN آیپی و یک نام میزبان پایدار یکی را انتخاب کنید، سپس تغییر نشانی را برنامهریزی کنید.
سرویس شما در https://10.60.0.25 میتواند TLS احرازشده داشته باشد حتی بدون نام DNS. نشانی همان هویتی است که کلاینت باید اعتبارسنجی کند و گواهی باید آن را دقیق توصیف کند. تصمیم این است که آیا آن نشانی بهاندازه کافی پایدار است که هویت باشد، یا نام میزبان نگهداری آسانتری دارد. VPN به دسترسپذیری پاسخ میدهد؛ به این پرسش پاسخ نمیدهد.
هویت و اعتماد را درست تنظیم کنید و یک URL مبتنی بر IP طراحی مشروعی است.
کلاینت در واقع چه چیزی را اعتبارسنجی میکند
کلاینت هویت مرجع در URL را با نامهای جایگزین موضوع در گواهی مقایسه میکند. برای یک نشانی IP، این یعنی یک ورودی iPAddress برابر با نشانی. یک نام رایج دوستانه جایگزین آن نیست.
RFC 9525 هویتهای نشانی IP را از نامهای DNS جدا میکند و قاعده تطبیق را تعریف میکند. قرار دادن نشانی فقط در برچسب موضوع یا بهعنوان ورودی نوع DNS تطبیقی ایجاد نمیکند. به همین دلیل SAN همان فیلدی است که هنگام ظاهر شدن هشدار باید بررسی شود.
اعتماد یک بررسی دوم و مستقل است. تطبیق نام زنجیره نامعتبر، گواهی منقضی یا گواهی صادرشده برای هدفی دیگر را درست نمیکند.
تصمیم یک: آیا نشانی بهاندازه کافی پایدار است که هویت باشد
اگر نشانی در تمام عمر استقرار ثابت باشد، گواهی SAN آیپی ساده و صادقانه است. اگر سرویس ممکن است جابهجا شود، هر جابهجایی به جایگزینی گواهی و بهروزرسانی هماهنگ کلاینت تبدیل میشود.
نام میزبان پایدار این وابستگی را کم میکند. کلاینتها از نام استفاده میکنند، DNS تأییدشده آن را به نشانی فعلی نگاشت میکند و تغییر نشانی دیگر تغییر هویت نیست. گواهی هنوز به تمدید نیاز دارد، اما URL تغییر نمیکند.
یک ورودی مدیریتشده در فایل hosts میتواند نگاشت را در محیط کوچک فراهم کند. این یک مسئولیت توزیع اضافه میکند؛ جایگزین تأیید TLS نمیشود.
تصمیم دو: چگونه کلاینت به صادرکننده اعتماد خواهد کرد
برای یک CA خصوصی، لنگر اعتماد را از طریق سازوکاری تأییدشده به دستگاههای موردنظر توزیع کنید. به کاربران نیاموزید که هشدارها را رد کنند یا گواهیای را که صفحه ورود به آنها میدهد نصب کنند. اگر گواهی مورد اعتماد عمومی میخواهید، پیش از برنامهریزی بر اساس آن، قواعد فعلی صادرکننده برای نشانیهای خصوصی را بررسی کنید. بیشتر صادرکنندگان عمومی یک IP خصوصی را بهعنوان هویت عمومی اعتبارسنجی نمیکنند.
مرورگر یا برنامه واقعی را بررسی کنید. مخزن اعتماد و رفتار اعتبارسنجی آن مهمتر از مستندات عمومی گواهی سیستمعامل است. آن را روی دستگاه واقعی بررسی کنید، نه فقط در کنسول.
ممکن است دروازه VPN همان ماشینی نباشد که برنامه وب را اجرا میکند، بنابراین فرض نکنید که گواهی تونل هر ارتباطی با این یکی دارد.
تغییر نشانی را پیش از رخ دادن برنامهریزی کنید
اگر 10.60.0.25 به 10.60.0.40 تبدیل شود، گواهی قدیمی دیگر URL را توصیف نمیکند. جایگزینی و بهروزرسانی کلاینت را با هم برنامهریزی کنید و هرگز در طول جابهجایی تأیید را غیرفعال نکنید.
هویتی را انتخاب کنید که کاربران تایپ میکنند یا برنامهها پیکربندی میکنند، سپس صدور، اعتماد، استقرار و تمدید را حول آن همتراز کنید. صفحهای قابل دسترسی با هشداری که رد شده، همان نتیجه سرویسی نیست که کلاینت هویت آن را تأیید میکند.