IKEv2 دو امضا دارد: گواهی و IKE_AUTH

تیکت شما می‌گوید گواهی SHA-256 است، در حالی که گزارش دروازه الگوریتم امضای دیگری را نام می‌برد و کسی پیش‌تر درخواست صدور دوبارهٔ CA را نوشته است. پیش از آنکه آن درخواست جایی برود، دو امضا را از هم جدا کنید: یکی مهر صادرکننده بر یک کلید عمومی است و دیگری اثبات همتا بر اینکه در هنگام IKE_AUTH کلید خصوصی متناظر را در اختیار دارد. اجزای مختلف آن‌ها را انتخاب می‌کنند و مجازند متفاوت باشند. خواندن هر یک از جایی که زندگی می‌کند دو فرمان و یک جدول می‌خواهد.

امضای صادرکننده را از گواهی بخوانید

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

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

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

امضای برخط را از تبادل IKE بخوانید

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

ipsec statusall | grep -i "auth\|proposal"

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

RFC 7427 چه چیزی را تغییر می‌دهد و چه چیزی را نه

روش‌های اصلی در RFC 7296 بر پایهٔ هر ترکیب الگوریتم شماره‌گذاری شده‌اند. افزونهٔ امضای RFC 7427 بعدی روش عمومی Digital Signature را با سیگنال‌دهی پشتیبانی از هش امضا می‌افزاید، بنابراین هش تازه دیگر به شمارهٔ روش اختصاصی نیاز ندارد. این موضوع مذاکره می‌شود، نه فرض: همتا افزونه را به دست نمی‌آورد چون کتابخانه‌اش می‌تواند همان گواهی‌ها را تجزیه کند، و همتایی که تنها روش‌های اصلی را پیاده می‌کند دروازه را وادار می‌کند یکی از آن‌ها را نگه دارد. این یک معاملهٔ سیاست با هزینهٔ سازگاری است، نه یک نقص.

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

چهار سطر در فهرست بگذارید

ثبتی که بحث را پایان می‌دهد چهار خط دارد، هر خط از جایی متفاوت خوانده شده و هر خط را شخصی متفاوت تغییر داده است. پیش از هر تصمیمی آن را پر کنید، چون سطر نادرست همان چیزی است که تعمیر را انتخاب می‌کند.

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

پروندهٔ قدیمی را بدون تضعیف PKI حل کنید

همتای قدیمی‌تر ممکن است تنها طرحی را پیشنهاد دهد که سیاست شما دیگر اجازه نمی‌دهد. گزینه‌ها عبارت‌اند از یک استثنای سازگاری زمان‌دار، به‌روزرسانی کلاینت، یا ترتیب احراز هویت متفاوت تنها برای همان همتا. بازسازی PKI حول امضای ضعیف‌تر گواهی، محدودیت تبادل برخط را برطرف نمی‌کند و هر سرویس دیگری را که به همان CA اعتماد دارد تضعیف می‌کند. ثبت کنید کدام سطر را تغییر دادید و استثنا کِی منقضی می‌شود.

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