کلاینت VPN شما پیش از اعتماد به یک گواهی چه چیزهایی را بررسی میکند
یک هشدار گواهی را از چهار دروازهای که کلاینت شما بررسی میکند بگذرانید: اعتماد به CA، ساخت زنجیره، نام و هدف همتا، و سیاست ابطال.
کلاینت VPN شما میگوید گواهی قابل بررسی نبود، و گفتوگو همانجا متوقف میشود. فایل هست، سرور بالا است، و همان پروفایل ماه گذشته روی لپتاپ دیگری کار میکرد. زیر آن هشدار یکخطی، کلاینت گواهی همتا را از چهار دروازه گذراند: یک مرجع صدور گواهی که خودتان پیکربندی کردهاید مسیر امضا را تضمین میکند، آن مسیر به مرجع میرسد، نام همتا همان نامی است که خواستهاید، و گواهی اکنون برای این هدف قابل استفاده است. دروازهای را که بسته شده پیدا کنید، و تعمیر معمولاً یک فایل است؛ اگر آن مرحله را رد کنید، تمام بعدازظهر بستهها را دوباره وارد میکنید.
پیش از ویرایش پروفایل، گفتوگو را بخوانید
متن خطاهای گواهی را کتابخانه زیرین مینویسد، نه محصول VPN که نصب کردهاید، پس همان رشتهٔ دقیق نخستین شاهد شماست. «امکان دریافت گواهی صادرکنندهٔ محلی نیست» به مسیر یا به لنگر اعتماد اشاره دارد. «گواهی منقضی شده یا هنوز معتبر نیست» به زمان اشاره دارد. «هدف گواهی پشتیبانی نمیشود» به کاربرد توسعهیافتهٔ کلید اشاره دارد. ناسازگاری نام به شما میگوید کدام نام را میخواسته. هیچیک از این چهار با نصب دوبارهٔ کلاینت درست نمیشود.
پیش از هر تغییری سطح گزارش را بالا ببرید. OpenVPN وقتی آن را با --verb 4 اجرا کنید شکست بررسی را حوالی دستدادن گزارش میکند، و strongSwan تصمیمهای هویت و زنجیرهٔ خود را در گزارش charon مینویسد. سپس تأیید کنید کدام گواهی را بررسی میکنید، چون مردم معمولاً فایل روی دیسک را آزمایش میکنند در حالی که پروفایل نسخهٔ قدیمیتری را درونخط میگذارد. وقتی پروفایل بلوکهای PEM را درون خود جای میدهد، گواهی درونخط همان چیزی است که آزمایش میشود.
مرجع صدور گواهی هویتها را امضا میکند، نه مجوزها را
مرجع یک نام و یک کلید امضا نگه میدارد. گواهیهایی صادر میکند که کلید عمومی را بر پایهٔ سیاست خودش به آن نام میبندند، همراه با پنجرهٔ اعتبار و محدودیتهای کاربرد. کلاینت شما برای شناختن صادرکننده فقط به گواهی مرجع نیاز دارد؛ هرگز به کلید امضا نیاز ندارد، و فرستادن آن کلید به کلاینتها به آنها توان ساختن هر هویتی را میدهد که استقرار به آن اعتماد دارد.
اعتماد به یک مرجع هر گواهیای را که امضا کرده است کاندید میکند، نه همتای درست را. گواهی یک وبسرور از همان CA داخلی هم کاندید است. به همین دلیل دروازههای نام و هدف وجود دارند، و به همین دلیل کلید بهخطرافتادهٔ CA از هر سرور تکی مهمتر است: به هر هویتی میرسد که مرجع تاکنون صادر کرده است. گواهیهای کلاینت را برای هر دستگاه جداگانه صادر کنید تا لپتاپ گمشده یک ابطال باشد، نه تولید دوبارهٔ کلید برای تمام استقرار.
مسیری را که کلاینت میکوشد بسازد دوباره بسازید
مسیر از گواهی همتا آغاز میشود، از صفر یا چند گواهی میانی میگذرد، و به ریشهای در مخزن اعتماد شما میرسد. گواهی میانی گمشده شایعترین خرابی زنجیره است، و از سمت کلاینت دقیقاً مثل ریشهٔ نامورد اعتماد به نظر میرسد. نخست برگه را بخوانید، سپس بگذارید OpenSSL مسیر را از موادی بسازد که قصد دارید بفرستید.
openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt
وضعیت خروج صفر یعنی مسیر از همان فایلها ساخته شده است؛ شکست، گواهیای را نام میبرد که به آن نرسیده. اگر openssl verify موفق شود ولی کلاینت همچنان امتناع کند، تفاوت در چیزی است که سرور واقعاً میفرستد یا در اینکه پروفایل کدام فایل اعتماد را بار میکند. در OpenVPN گواهیهای میانی میتوانند همراه فایل گواهی سرور بیایند یا با --extra-certs جداگانه ارائه شوند، و بستهای که دو ریشه با همان نام موضوع در خود دارد یکی از کلاینتهای شما را به شاخهٔ اشتباه میفرستد.
نام و هدف دو دروازهٔ جدا هستند
ساخت زنجیره هرگز نمیپرسد که آیا نام از آنِ شماست. OpenVPN فقط وقتی آن را بررسی میکند که پروفایل --verify-x509-name را تنظیم کند، و عادت قدیمی تطبیق تنها نام متداول روی گواهیهایی میشکند که هویتشان در subjectAltName زندگی میکند. استقرارهای IKEv2 هویت پیکربندیشده را با مدخلهای SAN یا با نام تمایزی میسنجند، بسته به کلاینت، و یک مقدار نویسهٔ عام یا %any بیصدا مقایسهای را که فکر میکردید دارید خاموش میکند.
سپس زمان و هدف میآیند. لپتاپی که ساعتش چند ساعت جلوست گواهیای را که هنوز معتبر نیست رد میکند، و گواهی میانی منقضی مسیر را خراب میکند در حالی که برگه جاری است. خرابیهای هدف از گواهیای میآید که serverAuth در کاربرد توسعهیافتهٔ کلید ندارد، یا keyUsage آن امضای دستدادن را مجاز نمیداند، که OpenSSL آن را هدف گواهی پشتیبانینشده گزارش میکند. از الگوی درست دوباره صادر کنید؛ هیچ چیز در آن پیام دلیل خاموشکردن بررسی نیست.
ابطال فقط وقتی اجرا میشود که کسی آن را پیکربندی کرده باشد
CRL یا پاسخ OCSP بهطور خودکار بررسی نمیشوند. روی سرور OpenVPN، گواهیهای کلاینت فقط وقتی با فهرستی سنجیده میشوند که --crl-verify به آن اشاره کند. بررسی سمت کلاینت برای گواهی سرور به پیادهسازی بستگی دارد و اغلب وجود ندارد. strongSwan پیش از نگاه به CRL برای یک همتا به افزونهٔ ابطال و یک سیاست نیاز دارد.
این بلیتی را توضیح میدهد که سرانجام دریافت میکنید: گواهی کلاینت ابطالشده هنوز وصل میشود، و همه نتیجه میگیرند که ابطال خراب است. هیچ چیز بررسی نمیکرد. CRL را منتشر و تازه کنید، یا گواهیهای کلاینت را آنقدر کوتاهعمر نگه دارید که ابطال کهنه مدت کوتاهی مهم باشد، و مسیر ابطال را با یک گواهی آزمایشگاهی تمرین کنید پیش از آنکه در هنگام یک رخداد به آن نیاز پیدا کنید.
ترتیب تعمیری که بررسی را روشن نگه میدارد
پیش از دستزدن به فایلها بر اساس نشانه مرتب کنید، چون هر ردیف جدول شما را به شیء متفاوتی میفرستد.
| Client says | Most likely gate | First check |
|---|---|---|
| unable to get local issuer certificate | trust anchor or missing intermediate | your own openssl verify against the files the profile loads |
| expired or not yet valid | validity window | leaf and intermediate dates against the device clock |
| unsupported certificate purpose | extended key usage | serverAuth present, keyUsage allows the handshake |
| name mismatch | peer identity | subjectAltName entries versus the profile name |
فهرست را در یک گذر انجام دهید: فایلی را که پروفایل بار میکند تأیید کنید، مسیر را خودتان بسازید، بررسی کنید که سرور گواهی میانی را میفرستد، ساعت را مقایسه کنید، SAN را بخوانید، EKU را بخوانید، سپس دوباره وصل شوید و ببینید همان خط گزارش ناپدید میشود. اگر به دستگاهی اصلاً نمیتوان CA داد، سنجاقکردن جایگزین صادقانه است، چون OpenVPN 2.6 مقدار --peer-fingerprint را میپذیرد و اعتماد را به یک کلید محدود میکند بهجای برداشتن بررسی. RFC 5280 مرجع معنای هر یک از این فیلدها است.