strongSwan: نوع کلید، بارگذار و backend اشتباه

پسوند فایل‌ها الگوریتم‌های کلید را مشخص نمی‌کنند و یک پوشش .pem می‌تواند مواد RSA یا ECDSA داشته باشد. PEM توصیف می‌کند که بایت‌ها چگونه بسته‌بندی می‌شوند، در حالی که RSA و ECDSA الگوریتم‌های متفاوتی را نام می‌برند، و فایل PKCS12 چیز سومی است. strongSwan اعتبارنامه‌ها را از طریق افزونه‌ها و یک backend پیکربندی بارگذاری می‌کند، بنابراین ممکن است گواهی در فهرستی دیده شود در حالی که کلید خصوصی هرگز قابل استفاده نشود. این لایه‌ها را پیش از ویرایش هر رازی جدا کنید.

رمزگذاری، الگوریتم و بسته‌بندی سه لایه‌اند

یک فایل کلید رمزگذاری، الگوریتم و اغلب یک محفظه دارد. PEM همان پوشش آشنای base64 است؛ DER همتای دودویی آن؛ PKCS12 گواهی را با کلید و زنجیره‌اش یکجا جمع می‌کند. فایل زنجیره گواهی محفظه دیگری است و معمولاً هیچ کلید خصوصی ندارد. هیچ‌یک از این برچسب‌ها نمی‌گوید مواد درون آن RSA است یا ECDSA.

الگوریتم را از خود شیء بخوانید. نام بازاریابی ارائه‌دهنده یا پسوند فایل مدرک نیست، زیرا همان صادرکننده می‌تواند انواع کلید متفاوت بدهد.

پیش از سرزنش بارگذار، کلیدهای عمومی را مقایسه کنید

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

ipsec.secrets قدیمی یا اعتبارنامه‌های swanctl

strongSwan دو مسیر اعتبارنامه رایج دارد. پشته قدیمی starter مدخل‌های مختص نوع را می‌خواند از ipsec.secrets، و هر مدخل باید نوع درست را برای مواد ذکر کند. پشته swanctl و vici کلیدها را از پوشه اعتبارنامه خود و از طریق پیکربندی خودش بارگذاری می‌کند. ویرایش فایلی که backend در حال اجرا آن را نمی‌خواند چیزی را تغییر نمی‌دهد.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

پیدا کنید کدام backend واقعاً در حال اجراست، سپس کلید را جایی بگذارید که آن backend نگاه می‌کند. راهنمای قدیمی strongSwan 5.9 مدخل‌های راز مختص نوع را تعریف می‌کند و مستندات swanctl نیست. مخلوط کردن این دو یک daemon می‌سازد که فایلی را نادیده می‌گیرد که مدیر آن را معتبر می‌داند. بارگذاری مجددی که خطایی گزارش نمی‌کند فقط یعنی پیکربندی تجزیه شده است.

رویداد بارگذاری و نتیجه احراز هویت را بخوانید

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

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