کپی کردن گواهی VPN کلید را کپی نمیکند
گواهی، کلید عمومی و هویت امضاشده را در خود دارد؛ کلید خصوصی آن جداگانه است. پیش از فرض اینکه یک کپی میتواند احراز هویت کند، بستهٔ صدور را بخوانید.
این راهنما از فهرست گواهیهای کارخواه آغاز میشود، جایی که هر ورودی فقط یک نام، یک صادرکننده و یک تاریخ انقضا نشان میدهد و دیگر هیچ. آن را صادر کنید، روی دستگاه دوم وارد کنید و اتصال رد میشود، چون کارخواه نمیتواند مالکیت کلید خصوصی را اثبات کند. فایل کاملاً کپی شده بود؛ خطا این است که انتظار داشته باشیم گواهی کلید خودش را همراه داشته باشد. پیش از انتخاب قالب، پنجرهٔ صدور را بخوانید و سپس فایلی را که واقعاً دریافت کردهاید بررسی کنید.
دو کلیک، دو محصول بسیار متفاوت.
پنجرهٔ صدور را بخوانید، نه پسوند فایل را
صدور گواهی DER یا PEM شامل یک کلید عمومی و ادعاهای هویت امضاشده است، یعنی همان چیزی که سرور برای اعتماد به شما لازم دارد و کارخواه برای بررسی سرور. بستهٔ PKCS#12 ظرفی است که میتواند گواهی، زنجیرهٔ آن و کلید خصوصی متناظر را در خود نگه دارد، محافظتشده با گذرواژه، هرچند میتوان آن را بدون کلید هم ساخت.
PEM فقط یک رمزگذاری متنی است، نه وعدهای دربارهٔ محتوا. یک پسوند میتواند یک گواهی واحد یا فایلی با چند بلوک برچسبدار را توصیف کند و گزینههای صدور تعیین میکنند کدامیک.
بنابراین پرسش سودمند هرگز این نیست که چه پسوندی گرفتید، بلکه این است که فایل چه بلوکهایی دارد. بستهای که بیکلید صادر شده هم بسته است. محتوا را بررسی کنید، نه محبوبیت قالب را.
آنچه واقعاً گرفتید را بررسی کنید
پیش از وارد کردن هر چیزی، برچسبها را بجویید، سپس فیلدهای گواهی را بخوانید تا تأیید کنید کدام هویت را در دست دارید. بررسیها را روی همان فایلی اجرا کنید که واقعاً وارد خواهد شد. پس از هر صدور دوباره، آنها را تکرار کنید، چون گزینهها ممکن است متفاوت باشند.
grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem openssl x509 -in client.crt -noout -subject -issuer -dates openssl pkey -in client.key -noout -text | head -5 openssl pkcs12 -info -in client.p12 -noout
صدوری که فقط بلوک گواهی دارد، شیئی عمومی است و نمیتواند احراز هویت کند. بلوک کلید بدون گواهی شما را بدون زنجیرهای میگذارد که سرور انتظار دارد. خروجی اطلاعات PKCS#12 هم گزارش میدهد که آیا کلیدی هست یا نه، و این پرسش را برای آن قالب یکسره میکند. الگوریتم و اندازهٔ کلید را هم نام میبرد و وقتی کلیدی در کار نباشد، کاملاً شکست میخورد.
هرگز فایلی که کلید خصوصی دارد را در رشتهٔ پشتیبانی، ردیاب مسئله یا گفتگو نچسبانید، حتی وقتی شبیه همان گواهی باشد که پیشتر به اشتراک گذاشتهاید. تصویرهای صفحه از پنل کلید هم همان احتیاط را میطلبند.
کلید ممکن است جایی باشد که نمیتوانید کپی کنید
روی دستگاههای مدیریتشده، کلید خصوصی میتواند در زنجیرهٔ کلید سیستمعامل، یک توکن سختافزاری یا یک محفظهٔ امن قرار بگیرد و سیاستی آن را غیرقابلصدور علامت بزند. آنگاه مدیر گواهی شیء عمومی را نشان میدهد در حالی که راز سر جای خود میماند و هیچ فرمان صدوری نسخهٔ قابلحمل تولید نمیکند. ثبتنام از طریق مدیریت دستگاههای همراه غالباً بر پایهٔ طراحی همینگونه کار میکند.
این یک کنترل است، نه مانعی برای دور زدن. بازسازی کلید خصوصی از گواهی عمومی ممکن نیست و هر ابزاری که چنین ادعایی کند، کار دیگری میکند.
به جای کپی کردن، هویت تازه ثبت کنید
مسیر پشتیبانیشده معمولاً این است که هویتی جداگانه برای دستگاه جدید ثبت کنید و هویت قدیمی را هنگام بازنشستگی باطل کنید، تا هر دستگاه جداگانه قابل جمعآوری باشد. جایی که صدور همراه کلید واقعاً تأیید شده است، فایل حاصل و گذرواژهاش را مانند اعتبارنامه بدانید: در حالت سکون رمزگذاریشده، از کانالی مورد اعتماد منتقلشده و پس از پایان ثبتنام پاکشده.
با احراز هویت بهوسیلهٔ هویت واردشده بررسی کنید، نه با تماشای موفقیت ورود. کارخواهی که گواهی عمومی را به انبار خود میپذیرد، چیزی دربارهٔ کلید اثبات نکرده است.
در پایان تأیید کنید که سرور هویت جدید را میپذیرد و هویت قدیمی هنوز همانگونه رفتار میکند که سیاست در نظر دارد. این راهنما با شواهد کامل میشود، نه با فایلی که درست به نظر میرسد.