گواهی کلاینت گم شده؟ با شماره سریال باطل کنید، نه با نام

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

گم شدن فایل به معنای گم شدن سابقه CA نیست

یک PKI از Easy-RSA گواهی‌های عمومی صادرشده را نگه می‌دارد و نسخه‌های کنونی نسخه‌هایی را نیز بر اساس سریال در پوشه certs_by_serial داخل PKI بایگانی می‌کنند. برای ابطال چیزی به کلید خصوصی نیاز نیست. آنچه اهمیت دارد گواهی دقیقی است که CA امضا کرده و CA از پیش آن را دارد.

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

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

پیش از هر چیز صادرکننده و سریال را بخوانید

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

مقادیر را با سوابق CA و با دستگاهی یا شخصی که فکر می‌کنید گواهی نزد اوست تطبیق دهید.

نام مشترک را می‌توان دوباره به کار برد و معمولاً هم همین کار انجام می‌شود. تا وقتی سریال‌ها نوشته نشده‌اند درباره اینکه کدام گواهی‌ها را پس بگیرید تصمیم نگیرید.

چرا ابطال گواهی تازه کاری نمی‌کند

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

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

هر دو خطا از برخورد با نام به‌عنوان هویت می‌آید.

گواهی‌ای را که سریال نام می‌برد باطل کنید

پیش از دست زدن به CA شیء را شناسایی کنید: openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates هر چهار مقدار را در یک گذر چاپ می‌کند و سریال همان چیزی است که با بایگانی CA تطبیق می‌دهید. Easy-RSA آن بایگانی را زیر pki/certs_by_serial نگه می‌دارد، با یک فایل به نام هر سریال. فرمان ابطال نام مشترک می‌گیرد نه سریال، پس فایل بایگانی‌شده را به pki/issued/<common-name>.crt کپی کنید و بگذارید نام به شیئی که شناسایی کردید اشاره کند. easyrsa revoke <common-name> را از پوشه PKI اجرا کنید، سپس بررسی کنید که سطر متناظر در index.txt به R برگشته باشد. سریال راه انتخاب شیء است، نه آرگومانی که فرمان می‌پذیرد.

openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates
cp pki/certs_by_serial/A1B2C3D4.pem pki/issued/client-01.crt
./easyrsa revoke client-01
grep -n client-01 pki/index.txt
./easyrsa gen-crl

اگر index.txt مقدار R را نشان نمی‌دهد، بایستید و پیش از تولید CRL خطا را بخوانید، زیرا CRLی که از سابقه‌ای هنوز معتبر ساخته شود چیزی را پس نمی‌گیرد. تنها پس از برگشتن سطر است که easyrsa gen-crl را اجرا می‌کنید و به توزیع فایل می‌روید.

CRL را جایی منتشر کنید که واقعاً اعمال می‌شود

CRL تازه‌ای از طریق گردش‌کار پشتیبانی‌شده PKI بسازید، سپس آن را در هر تأییدکننده‌ای منتشر کنید که ابطال‌های این صادرکننده را اعمال می‌کند.

فایل به‌روزشده‌ای که روی CA می‌ماند چیزی را تغییر نمی‌دهد، زیرا VPN تصمیم را در تأییدکننده خودش نهایی می‌کند. صادرکننده CRL، بازه اعتبار و سریال‌های باطل‌شده را بررسی کنید و تأیید کنید که سرویس فایل را دوباره بارگذاری می‌کند نه اینکه قبلی را ذخیره کند. مالکیت و مسیر به اندازه محتوا اهمیت دارند: CRLی که دیمن نمی‌تواند بخواند از نبود CRL قابل تشخیص نیست. گزینه crl-verify در OpenVPN نام فایلی را می‌آورد که دیمن می‌خواند، پس آن مسیر و مالکیت فایل را در پیکربندی سرور بررسی کنید.

با یک تلاش اتصال واقعی تأیید کنید، نه با زمان فایل.

بدانید CRL چه وقت ابزار نادرست است

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

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

سریال، CRL و مرحله توزیع را در یک یادداشت نگه دارید تا حسابرسی بعدی به خواندن تبدیل شود. پروژه Easy-RSA فرمان‌های پشتیبانی‌شده برای نسخه‌ای که نصب کرده‌اید را مستند می‌کند و این تنها رابطی است که ارزش پیروی دارد.