درخواست کلید OpenVPN پس از OpenSSL 3: ارائه‌دهنده را بررسی کنید
درخواست ناگهانی کلید خصوصی اغلب پیامد تغییر ارائه‌دهنده است، نه یک گذرواژه تازه. کلید را بررسی کنید، هر دو مجموعه ارائه‌دهنده را بیازمایید و عبارت عبور را نگه دارید.
هیچ‌کس به پروفایل دست نزده است، با این حال همان کارخواه اکنون هر بار که راه می‌افتد عبارت عبور کلید خصوصی را می‌خواهد. وقتی این تغییر چند روز پس از ارتقای توزیع رخ می‌دهد، ارتقا علت محتمل است: OpenSSL 3 پشتیبانی الگوریتمی خود را بازسازمان داد و کلیدی که کتابخانه قدیمی بی‌زحمت می‌خواند می‌تواند بدون تغییر حتی یک بایت ناخوانا شود. بررسی‌ها را به ترتیب انجام دهید، چون دو تای آنها اگر فقط به درخواست نگاه کنید یکسان به نظر می‌رسند.
پرسش نخست این است که آیا کلید رمزگذاری شده است، و دومی این است که آیا این ساخت می‌تواند آن را رمزگشایی کند. تغییر پیکربندی تنها پس از دانستن هر دو پاسخ معنا دارد.
بررسی کنید که آیا کلید رمزگذاری شده است
خط اول پرونده را بخوانید و سپس بگذارید کتابخانه آن را تجزیه کند، چون نام پرونده چیزی را اثبات نمی‌کند. یک بلوک PEM با برچسب ENCRYPTED PRIVATE KEY همان PKCS#8 رمزگذاری‌شده است، و یک بلوک RSA PRIVATE KEY قدیمی‌تر که Proc-Type: 4,ENCRYPTED را حمل می‌کند شکل سنتی است، و هر دو عبارت عبور می‌خواهند. بلوک PRIVATE KEY رمزگذاری‌نشده اصلاً نباید چنین چیزی بخواهد. تجزیه را با حسابی اجرا کنید که مالک پرونده است، چون مشکل مجوز خطای متفاوت و بسیار کم‌جاذبه‌تری تولید می‌کند.
اگر کلید واقعاً رمزگذاری نشده و کارخواه همچنان می‌پرسد، از رمزنگاری چشم بردارید و بررسی کنید آیا پروفایل پرونده askpass را نام می‌برد که سرویس هنوز می‌تواند بخواند.
بررسی کنید که آیا این ساخت می‌تواند آن را رمزگشایی کند
OpenSSL 3 پشتیبانی الگوریتمی خود را میان ارائه‌دهندگان تقسیم کرد و مجموعه‌ای از رمزهای قدیمی‌تر اکنون در ارائه‌دهنده legacy قرار دارد نه در ارائه‌دهنده پیش‌فرض. کلیدی که با یکی از آن رمزها رمزگذاری شده معتبر می‌ماند، اما کتابخانه‌ای که بدون ارائه‌دهنده legacy بارگذاری شده نمی‌تواند آن را رمزگشایی کند. در برخی کارخواه‌ها این به صورت درخواستی تکرارشونده و در برخی دیگر به صورت شکستی سخت بلافاصله پس از عبارت عبور ظاهر می‌شود.
همان کلید را دو بار با همان باینری تجزیه کنید: نخست فقط با ارائه‌دهنده پیش‌فرض، سپس با legacy و پیش‌فرض که هر دو در خط فرمان خواسته شده‌اند. اگر تلاش دوم جایی موفق شود که اولی شکست خورد، تشخیص بر شواهد استوار است نه بر زمان ارتقا. اگر هر دو یکسان شکست بخورند، عبارت عبور نادرست است یا پرونده آسیب دیده، و هیچ تنظیم ارائه‌دهنده هیچ‌کدام را درست نمی‌کند.
باریک‌ترین اصلاح موجود را بررسی کنید
تغییر محدود به کارخواه را بر تغییر سراسری سیستم ترجیح دهید. برخی ساخت‌های 2.6 گزینه‌ای در پروفایل می‌پذیرند که هر دو ارائه‌دهنده را برای فرایند آن دیمن بارگذاری می‌کند، پس پیش از تکیه بر آن دستور را در راهنمای نسخه دقیق خود تأیید کنید؛ ویرایش openssl.cnf سیستم به جای آن بر هر برنامه OpenSSL روی میزبان اثر می‌گذارد. تنظیم باریک‌تر پس از رمزگذاری دوباره کلید نیز بسیار آسان‌تر برگشت‌پذیر است.
برای اینکه درخواست از میان برود، عبارت عبور را حذف نکنید. این کار یک اعتبارنامه محافظت‌شده را به پرونده متنی ساده تبدیل می‌کند و بی‌صدا خطر هر پشتیبان، رونوشت و بسته پشتیبانی را که در آن ظاهر می‌شود تغییر می‌دهد. تفاوت مهم میان کلیدی است که عبارت عبورش را لازم دارد و کلیدی که این کتابخانه نمی‌تواند رمزگشایی کند.
زمینه سرویس را بررسی کنید، سپس دوباره رمزگذاری کنید
وقتی کلید باز شد، آن را با الگوریتمی امروزی دوباره رمزگذاری کنید تا وابستگی از میان برود. پرونده تازه را با رمزی مدرن بنویسید، بررسی کنید که تجزیه می‌شود، پروفایل را به‌روز کنید و رونوشت قدیمی را تنها تا موفق شدن یک اتصال نگه دارید. هرگز عبارت عبور را در خط فرمان نگذارید، جایی که هر کاربر محلی می‌تواند آن را از فهرست فرایندها بخواند. پرونده قدیمی را تنها پس از آن حذف کنید که پرونده تازه از حساب سرویس متصل شده باشد، نه فقط از صدف خودتان.
سپس واحدی را بررسی کنید که واقعاً کارخواه را اجرا می‌کند. کلیدی که در صدف شما خوانا است ممکن است برای سرویسی که زیر حساب دیگری یا با تنظیم سخت‌شده پوشه خانه اجرا می‌شود ناخوانا باشد.
تنظیم ارائه‌دهنده را کنار پروفایل ثبت کنید و آزمون دو فرمانی را همراه آن نگه دارید. وقتی ارتقایی بعدی ارائه‌دهنده legacy را حذف کرد، آن آزمون را دوباره اجرا کنید تا ببینید آیا کلید هنوز به آن نیاز دارد یا پروفایل را می‌توان از این راه‌حل موقت بیرون آورد.
درخواست نشانه‌ای است با دست‌کم سه علت، و تنها یکی از آنها عبارت عبور گم‌شده است.