برای یک لپ‌تاپ دیگر به یک گواهی دیگر نیاز دارید، اما نخستین آموزش در نتایج جست‌وجو با فرمانی آغاز می‌شود که پوشه PKI را پاک می‌کند. آن فرمان به راه‌اندازی اولیه تعلق دارد، نه به ثبت؛ اجرای آن CA، تاریخچه صدور و همه نمایه‌های کلاینتی را که به صادرکننده قدیمی اعتماد داشتند از بین می‌برد. تصمیم باریک‌تر است: آیا صادرکننده شما هنوز وضعیت قابل استفاده دارد و آیا دستگاه تازه با سیاست ثبت شما سازگار است؟ سه شرط آن را تعیین می‌کند و تنها یکی بازسازی را توجیه می‌کند.

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

راه‌اندازی دوباره PKI پوشه را با ساختاری خالی جایگزین می‌کند: کلید و گواهی CA تازه، پایگاه صدور خالی و شمارنده سری جدید. کلاینت‌ها خودبه‌خود پیروی نمی‌کنند؛ نمایه‌هایشان CA قدیمی را سنجاق کرده‌اند، پس هر دستگاه باید دوباره ثبت شود و دستگاه‌های دور از دسترس به‌صورت دستی.

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

کپی کلید خصوصی CA در کنار سرور در حال اجرا میان‌بر دیگری است که باید رد کنید: مرجع امضایی که باید بیرون از شبکه بماند را به پرونده‌ای دیگر روی میزبانی با ترافیک نامعتبر تبدیل می‌کند.

شرط یکم: آیا وضعیت صادرکننده هنوز در دسترس است؟

پیش از هر تصمیمی پوشه‌ای را که سرور واقعاً به آن اعتماد دارد پیدا کنید. گواهی‌ای که سرور به‌عنوان CA ارائه می‌دهد را با گواهی در پوشه PKI بر پایه اثر انگشت مقایسه کنید، نه نام پرونده:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

اگر اثر انگشت‌ها یکی باشند، ثبت افزایشی است و نباید چیزی را بازسازی کنید. اگر متفاوت باشند، با CA ای امضا می‌کنید که سرور به آن اعتماد ندارد: گواهی بی‌دردسر نصب می‌شود و در دست‌دادن شکست می‌خورد، و آن خطا ساعت‌ها به‌اشتباه نقص کلاینت تشخیص داده می‌شود.

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

شرط دوم: کلید خصوصی تازه نزد چه کسی است؟

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

با Easy-RSA 3 در برابر CA موجود، وارد کردن و امضای درخواست دو فرمان است:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

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

شرط سوم: آیا سرور بیش از گواهی می‌خواهد؟

برای سرور معمولی OpenVPN با احراز هویت گواهی، گواهی همان ثبت است: نام مشترک هویت کلاینت می‌شود و هر پوشه، مسیر ارسالی یا نشانی ثابت به آن نام گره می‌خورد. گواهی را اضافه کنید و پیکربندی را فراموش کنید: تونل وصل می‌شود اما مسیرهای لازم هرگز ظاهر نمی‌شوند.

سکوها این را تغییر می‌دهند. OpenVPN Access Server پایگاه کاربران خودش را دارد، پس گواهی امضاشده حساب نیست؛ حساب باید وجود داشته باشد و مجاز باشد. درگاه‌های دیگر رشته هویت را به گروه نگاشت می‌کنند. ثبت یک دستگاه معمولاً دو سامانه را لمس می‌کند و گواهی تنها اولی است.

روش افزایشی و زمانی که بازسازی درست است

ترتیبی که یک دستگاه را بی‌آسیب اضافه می‌کند: صادرکننده را با اثر انگشت تأیید کنید، نسخه پشتیبان تازه از پوشه PKI بگیرید، درخواست را برای نقش کلاینت وارد و امضا کنید، گواهی را با زنجیره‌اش از مسیر تأییدشده برسانید و پیش از اتصال کاربر بررسی کنید:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

خط هدف باید SSL client را نشان دهد. کار را با به‌روزرسانی نسخه پشتیبان CA پس از صدور تمام کنید، زیرا نسخه‌ای که پیش از ثبت سری تازه گرفته شده وضعیتی بدون دستگاه تازه بازمی‌گرداند.

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

مقالات مرتبط