گواهی VPN اشتباه را باطل کردید؟ گزینه‌ها و محدودیت‌های بازیابی

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

گواهی را شناسایی کنید، نه شخص را

نام‌های رایج تکرار می‌شوند. کاربری که سه‌ماهه گذشته دوباره ثبت‌نام کرده ممکن است دو گواهی با همان CN و شماره‌های سریال متفاوت داشته باشد، و ابطال یکی دیگری را فعال نگه می‌دارد. ابتدا شیء دقیق را مشخص کنید:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

شماره سریال، صادرکننده، تاریخ ابطال و دلیلی که در CRL ثبت شده را بنویسید. سپس تأیید کنید کدام دستگاه‌ها آن شماره سریال را ارائه می‌دهند، زیرا گواهی باطل‌شده ممکن است هنوز روی یک لپ‌تاپ، یک تلفن و یک روتر یدکی نصب باشد، و جایگزینی که فقط به یکی از آن‌ها می‌رسد، حادثه دومی ایجاد می‌کند.

یک بررسی رفتاری سریع وضعیت را بدون تغییر چیزی تأیید می‌کند:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

اگر گواهی را باطل گزارش کند، CRL و کلاینت هم‌نظرند؛ اگر پاک تأیید شود، کلاینتی که در دست دارید همان باطل‌شده نیست و جست‌وجو ادامه می‌یابد.

بررسی کنید CA از تعلیق یا ابطال دائمی استفاده کرده است

RFC 5280 certificateHold را وضعیتی موقت و removeFromCRL را سیگنال آزادسازی آن تعریف می‌کند. آن چرخه عمر واقعی است، اما دکمه واگرد عمومی نیست. خواندن کد دلیل به شما می‌گوید آیا صادرکننده هرگز قصد پشتیبانی از آزادسازی را داشته است.

تله این است که فرض کنید قصد موقت به معنای رکورد موقت است. اگر ورودی CA حاوی keyCompromise یا cessationOfOperation باشد، گواهی صرف‌نظر از آنچه شخص تازه‌کننده دکمه قصد داشت، دائماً باطل است. برعکس، ورودی با علامت certificateHold روی CAیی که آزادسازی تعلیق را پیاده‌سازی نمی‌کند در عمل دائمی است، زیرا هیچ‌چیز هرگز آزادسازی را منتشر نخواهد کرد.

CAهای مبتنی بر OpenSSL این محدودیت را نشان می‌دهند. فرمان ca مقادیر -crl_reason را می‌پذیرد، از جمله certificateHold و removeFromCRL، اما CRLهای دلتا تولید نمی‌کند — مستندات OpenSSL CA این محدودیت را برای خروجی CRL خود ذکر می‌کند. CRL کامل که صرفاً شماره سریال را حذف می‌کند مدل انتشار متفاوتی از دلتایی است که می‌گوید "این ورودی آزاد شد"، بنابراین چسباندن removeFromCRL در یک CA VPN مبتنی بر OpenSSL آزادسازی تعریف‌شده در استانداردها را تولید نمی‌کند.

اگر کلید ممکن است افشا شده باشد، آن را جایگزین کنید

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

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

استدلال راحتی برای بازگرداندن گواهی قدیمی واقعی است، اما باید صریح پاسخ داده شود، نه در سکوت. "کاربر امروز به دسترسی نیاز دارد" دلیلی برای تسریع صدور است، نه دلیلی برای لغو ابطال کلیدی که نمی‌توانید درباره آن پاسخگو باشید.

اگر خطای اداری بود، تحت کنترل جایگزین کنید

وقتی ابطال صرفاً اشتباه بود و کلید هرگز افشا نشد، ترمیم همچنان جایگزینی کنترل‌شده است نه ویرایش. از فرایند پشتیبانی‌شده صادرکننده استفاده کنید، شماره سریال و تاریخچه صدور را دست‌نخورده نگه دارید و از دو میان‌بر وسوسه‌انگیز بپرهیزید: چرخاندن نویسه وضعیت در index.txt از R به V، و حذف ردیف صدور تا گواهی جدید بتواند شماره سریال را دوباره به کار ببرد.

در CA OpenSSL پایگاه داده با تب جدا شده و به‌راحتی اشتباه خوانده می‌شود، و همین ویرایش دستی را جذاب می‌کند:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

آن را بخوانید، ننویسید. ویرایش فایل CRL بعدی را بدون هیچ رد حسابرسی تغییر می‌دهد، و هر نمونه دوم CA یا نسخه پشتیبانی که هنوز ردیف اصلی را دارد بعداً با آن اختلاف پیدا می‌کند.

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

پذیرش تازه را تأیید کنید و سابقه را نگه دارید

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

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

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