گواهی VPN لغوشده هنوز متصل میشود؟ اجرای CRL را بررسی کنید
گواهیهای لغوشده هنوز متصل میشوند وقتی CRL هرگز به تأییدکننده نمیرسد. به این ترتیب صادرکننده، شماره سریال بارگذاریشده، رفتار بازبارگذاری و نشستهای فعال را بررسی کنید.
گواهی را لغو کردید، فهرست تازهای ساختهاید، و نمایهٔ قدیمی هنوز تونلی بالا میآورد. خود لغو خراب نیست: CRL یک اعلامیهٔ امضاشده است که یک شماره سریال دیگر معتبر نیست، و دسترسی را تنها زمانی تغییر میدهد که مؤلفهٔ پایانیاب TLS آن را برای صادرکنندهٔ درست بارگذاری کند، پیش از آنکه تصمیم پذیرش را بگیرد. بیشتر این موارد همانجا هستند، و به همین دلیل لغو و رد دو واقعیت جداگانهاند.
پنج بررسی زیر را به ترتیب انجام دهید و در اولین موردی که برقرار نیست بایستید، زیرا هر بررسی بعدی درستی بررسیهای پیشین را فرض میکند.
بررسی کنید کدام مؤلفه تصمیم پذیرش را میگیرد
فرایندی را نام ببرید که گواهی مشتری را اعتبارسنجی میکند، زیرا تنها همان فرایند میتواند فهرستی را اجرا کند. روی سرور OpenVPN خود دیمن است که با crl-verify پیکربندی شده است. در ocserv خط crl در ocserv.conf است. در strongSwan ورودیها CRLهای بارگذاریشده همراه با strictcrlpolicy هستند. پروکسی یا دستگاهی که TLS را پیش از VPN پایان میدهد نیز میتواند تأییدکنندهٔ واقعی باشد، و اگر چنین باشد، دیمن پشت آن هرگز گواهی مشتری را نمیبیند.
WireGuard در دستهٔ دیگری است. نه گواهی دارد و نه فهرست لغو؛ همتا با کلید عمومیاش در پیکربندی پذیرفته میشود، پس پایان دادن به دسترسی یعنی حذف آن کلید. اگر در استقراری فقط با WireGuard به دنبال CRL میگردید، آن سازوکار آنجا نیست.
مراقب تلهٔ سمت مشتری هم باشید. مشتریای که از اتصال سر باز میزند چون گواهی سرور را نمیپسندد، زنجیرهٔ سرور را اجرا میکند و اعتبارنامهٔ خودش را لغو نمیکند. گواهی کاربر تنها جایی لغو میشود که همان گواهی کاربر اعتبارسنجی میشود، و این تقریباً همیشه سمت سرور است.
بررسی کنید فهرست برای کدام صادرکننده امضا شده است
CRL به یک CA صادرکننده محدود است. با یک ریشه و یک میانی، گواهیهای برگ از میانی میآیند، پس فهرست مهم CRL میانی است؛ فهرست ریشه چیزی دربارهٔ آن برگها نمیگوید. تأییدکنندهای که به فایل اشتباه اشاره میکند آن را بشاش تجزیه میکند، هیچ ورودی منطبقی نمییابد و همه چیز را میپذیرد.
پیش از دست زدن به دیمن، جفتشدن را تأیید کنید. صادرکنندهٔ روی گواهی باید با subject فهرست مطابقت داشته باشد:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateوقتی هر دو از یک CA میآیند، شماره سریال چاپشده برای گواهی همان مقداری است که باید در فهرست بیاید. اگر همخوانی ندارند، CRL نادرست یا نسخهٔ نادرست آن را در دست دارید.
اعتبار به همان بررسی تعلق دارد. nextUpdate در گذشته فهرست را کهنه میکند، و تأییدکنندهای که بسته شکست میخورد آنگاه هر مشتری را به جای فقط مشتری لغوشده رد میکند.
بررسی کنید شماره سریال در نسخهای است که دیمن بارگذاری کرده
لغو یک ورودی در پایگاهدادهٔ CA مینویسد، و بازتولید فایل تازهای مینویسد. هیچیک از این دو کار به دیمن در حال اجرایی که نسخهٔ کهنه را هنگام راهاندازی بارگذاری کرده نمیرسد. فهرست را خالی کنید و شماره سریال را جستوجو کنید:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlسپس بررسی کنید پیادهسازی شما فایل را چگونه برمیدارد. OpenVPN مسیری را که به crl-verify داده شده یک بار هنگام راهاندازی میخواند، پس فهرست تازه به راهاندازی دوباره یا سیگنال راهاندازی دوباره نیاز دارد؛ همان گزینه اگر به پوشه اشاره کند در هر اتصال دوباره خوانده میشود، و به همین دلیل حالت پوشه وجود دارد. strongSwan باید اعتبارنامههایش را بازبارگذاری کند، مثلاً با swanctl --load-creds. درست بودن فایل روی دیسک و استفادهٔ تأییدکننده از آن دو واقعیت جداگانهاند.
سیاست فهرست گمشده یا منقضی را بررسی کنید
این تصمیمی است که بسیاری از استقرارها هرگز آشکارا نمیگیرند، و تعیین میکند لغو از شما محافظت میکند یا همه را بیرون قفل میکند. Fail-closed یعنی بدون اطلاعات لغو قابل استفاده رد رخ میدهد؛ fail-open یعنی تأییدکننده بدون آن ادامه میدهد. strongSwan گزینه را به صورت strictcrlpolicy ارائه میدهد. OpenVPN با crl-verify از راهاندازی روی فایلی که نمیتواند بخواند یا تجزیه کند سر باز میزند، و فهرست منقضی به صورت خطای تأیید TLS دربارهٔ CRL منقضی ظاهر میشود نه پذیرش خاموش.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
هر جهتی را انتخاب کنید، خودکارسازی مهمتر از انتخاب است: کاری که CRL را پیش از nextUpdate بازتولید میکند، و هشداری وقتی نسخهٔ مستقرشده کهنه میشود، نمیگذارند هیچیک از دو سیاست به حادثه تبدیل شود. بررسی برخط با OCSP تازگی را به پاسخدهنده منتقل میکند، اما همان قاعده برقرار است، زیرا تأییدکنندهای که برای بررسی پاسخ پیکربندی نشده چیزی را تغییر نمیدهد.
نشست فعال را بررسی کنید، سپس نسخههای کلید
لغو در جریان اعتبارسنجی گواهی ارزیابی میشود که هنگام اتصال و هنگام مذاکرهٔ دوباره رخ میدهد. نشست برقرارشده تا زمانی که دوباره مذاکره کند ادامه مییابد، و پیشفرض OpenVPN یک بار در ساعت با reneg-sec 3600 است. اگر شخص باید همین حالا از شبکه بیرون باشد، نشست را همراه با انتشار فهرست پایان دهید و سپس تأیید کنید که اتصال دوباره رد میشود.
اعتبارنامه را از نسخههایش جدا کنید. حذف نمایه روی یک لپتاپ مانع احراز هویت نسخهٔ دیگری از همان کلید خصوصی نمیشود؛ لغو همان چیزی است که هر نسخه را بیفایده میکند، و تنها وقتی بررسیهای پیشین برقرار باشند. به دستگاه جایگزین گواهی خودش را بدهید تا یکی بدون دست زدن به دیگری لغو شود.
پیش از آنکه آن را تمامشده بدانید: مؤلفهٔ اعتبارسنج مشخص شده، صادرکنندهٔ فهرست با صادرکنندهٔ برگ مطابقت دارد، شماره سریال لغوشده در نسخهای است که دیمن واقعاً بارگذاری کرده، سیاست فهرستهای گمشده یا منقضی آگاهانه و پایششده است، و نشست فعال پایان یافته است نه منتظرش ماندهاند. قالبهای پشت همهٔ اینها در RFC 5280 مشخص شدهاند.