گواهی IKEv2 و SAN: چرا بررسی هویت شکست می‌خورد
یک گواهی معتبر IKEv2 باز هم شکست می‌خورد وقتی هویت مورد انتظار و نوع SAN همخوانی ندارند. DNS را با DNS و IP را با IP تطبیق دهید و نخست پروفایل را بررسی کنید.
زنجیره گواهی شما به یک CA مورد اعتماد می‌رسد، تاریخ‌ها درست هستند، و همتا باز هم از تکمیل فاز 1 با خطای هویت سر باز می‌زند. دسترس‌پذیری و امضای معتبر فقط نیمی از چیزی است که یک کلاینت IKEv2 بررسی می‌کند. نیم دیگر این است که آیا هویت مورد انتظار در گواهی و در فیلد درست ظاهر می‌شود، و این انتظار را پروفایل تعیین می‌کند، نه نام فایل گواهی.
نشانه همیشه یک شکل است
پروفایل اتصال از نام میزبان به نشانی IP تغییر می‌کند، یا از گواهی‌ای که نام DNS داشت به گواهی‌ای که فقط نشانی دارد تمدید می‌شود، و تونل مذاکره را متوقف می‌کند. هیچ چیز در مسیر شبکه تغییر نکرده است. کلاینت به همتا می‌رسد، گواهی می‌گیرد و هویت همتا را رد می‌کند چون شناسه‌ای که قرار بود انتظارش را داشته باشد در فیلدی که می‌پذیرد نمایانده نشده است. تمدیدها محرک معمول‌اند، چون گواهی جانشین غالباً از قالبی متفاوت با گواهی جایگزین‌شده می‌آید.
سپس هر دو طرف چیز بی‌فایده‌ای ثبت می‌کنند، و به همین دلیل خطا معمولاً به‌عنوان مشکل گواهی گزارش می‌شود. گزارش کلاینت ممکن است هویتی را که می‌خواست نام ببرد، و همان نام سرنخ مورد نظر شماست، نه تاریخ انقضا.
نوع شناسه را تطبیق دهید، نه فقط مقدار را
SAN از نوع dNSName و SAN از نوع iPAddress فیلدهای متفاوتی با قواعد تطبیق متفاوت هستند، پس گواهی‌ای که 203.0.113.10 را به‌صورت رشته DNS دارد کلاینتی را که هویت IP انتظار دارد راضی نمی‌کند. اعتبارسنج‌های امروزی تا حد زیادی نام عمومی را نادیده می‌گیرند، پس برچسب دوستانه در جزئیات گواهی چیزی را درباره آنچه تطبیق می‌یابد ثابت نمی‌کند. اگر در هنگام عیب‌یابی نام میزبان با نشانی جایگزین شده باشد، فرض کنید هویت مورد انتظار همراه آن جابه‌جا شده تا اینکه بررسی کنید. رشته پروفایل را با رشته SAN نویسه به نویسه مقایسه کنید، چون یک نقطه در پایان یا یک فاصله اضافی کافی است.
نویسه‌های عام فقط برای DNS یک تسهیل است و قواعد تطبیق خودش را دارد، و این دلیل دیگری است که پروفایل مبتنی بر IP هرگز نباید به آن‌ها تکیه کند.
بیابید هر کلاینت انتظار را کجا نگه می‌دارد
در strongSwan مقدار مقایسه‌شده با گواهی از تنظیم هویت همتا می‌آید: rightid در پیکربندی کلاسیک، یا id بخش اتصال راه‌دور در swanctl. مستندات درباره هم‌کارکردی با Apple IKEv2 اینجا سودمند است چون قراردادهای هویتی را که کلاینت پروفایل‌محور به کار می‌برد روشن می‌کند، و آن قراردادها دسته‌ای از ناسازگاری را توضیح می‌دهند که روی شبکه تصادفی به نظر می‌رسد.
پروفایل‌های پیکربندی Apple فیلدی برای شناسه راه‌دور دارند، و مقدار آنجا همان چیزی است که کلاینت بررسی می‌کند، نه نشانی سرور در تنظیمات اتصال. کلاینت‌های Windows و دستگاه‌ها هر یک فیلد خودشان را با پیش‌فرض خودشان دارند، و پیش‌فرض غالباً از نشانی‌ای که تایپ کرده‌اید پیروی می‌کند. وقتی دو فیلد اختلاف دارند، فیلدی که کلاینت واقعاً می‌خواند برنده است، و به‌ندرت همان فیلدی است که ویرایش کرده‌اید.
پروفایل یا گواهی را آگاهانه اصلاح کنید
گواهی همتا را با ابزارهای تأییدشده بررسی کنید و ورودی‌های SAN را با نوع‌هایشان فهرست کنید پیش از آنکه چیزی را تغییر دهید. این بررسی نه کلید خصوصی می‌خواهد نه بارگذاری، و موضوع را در چند ثانیه روشن می‌کند. اگر استقرار یک هویت DNS را در نظر دارد، گواهی باید آن را به‌صورت ورودی dNSName داشته باشد، و اگر نشانی را در نظر دارد، گواهی برای دقیقاً همان نشانی به ورودی iPAddress نیاز دارد.
وقتی گواهی نادرست است، از اپراتور گواهی اصلاح‌شده با شناسه مورد انتظار مشخص بخواهید. وقتی پروفایل نادرست است، پروفایل را اصلاح کنید و گواهی را رها کنید. خاموش کردن اعتبارسنجی هویت خطا را ناپدید می‌کند و بررسی اینکه تونل با همتای مورد نظر شما سخن می‌گوید را برمی‌دارد.
هویت مورد انتظار را برای هر سکوی کلاینت مستند کنید، چون مقداری که یک کلاینت به‌طور خودکار استخراج می‌کند شاید در دیگری نیاز به تصریح داشته باشد.
چهار واقعیت به درخواست تمدید بدهید
شناسه مورد انتظار و نوعش، ورودی‌های SAN که گواهی کنونی واقعاً دارد، کلاینت و نسخه‌ای که بررسی را انجام می‌دهند، و متن دقیق خطا را بنویسید. درخواست تمدیدی که از این چهار خط ساخته شود بار اول گواهی درست را می‌گیرد، نه گواهی دیگری با همان نام فایل آشنا.