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

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

با سیاست نام‌گذاری‌ای که سرور استفاده می‌کند شروع کنید

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

پیکربندی سرور را بخوانید و توجه کنید کدام منبع هویت در کار است. username-as-common-name نام کاربری احراز‌شده را به نام مؤثر برای جست‌وجوهای مخصوص مشتری تبدیل می‌کند. بدون آن، نام مشترک موضوع از گواهی استفاده می‌شود. هر پاسخی که باشد، پیش از دست زدن به هر فهرست مجاز آن را بنویسید.

دو مسیر مجموعه متفاوتی از نام‌های مجاز برای همان گواهی تولید می‌کنند. حدس زدن در اینجا یعنی ویرایش فایل اشتباه و نتیجه‌گیری اینکه کنترل کار نمی‌کند.

بررسی کنید چه چیزی واقعاً مشتری را می‌پذیرد

یک client-config-dir با فایل منطبق گزینه‌های هر مشتری را فراهم می‌کند؛ به‌تنهایی قاعده پذیرش نیست. پذیرش با نام نیازمند ccd-exclusive است، که مشتریانی را که فایل منطبق ندارند رد می‌کند. فعال‌کردن آن روی یک استقرار فعال همه کسانی را که نامشان فایل ندارد قطع می‌کند، پس پیش از تغییر هر چیزی فایل‌ها را بشمارید.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

شمارش همان بررسی است: فهرست پوشه را با هویت‌هایی که انتظار دارید متصل شوند مقایسه کنید.

سپس تأیید کنید که هر نام فایل دقیقاً با هویت مؤثر مطابقت دارد، از جمله حروف بزرگ و کوچک و فاصله‌ها. یک فایل برای office-laptop برای گواهی‌ای که موضوعش Office-Laptop خوانده می‌شود کاری نمی‌کند. فاصله‌های انتهایی نیز از یک فهرست ساده پنهان می‌مانند، و این‌گونه فایلی که موجود به نظر می‌رسد خوانده‌نشده می‌ماند.

CRL‌ای را که دروازه بارگذاری می‌کند بررسی کنید

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

مسیر پیکربندی‌شده، تاریخ صدور و فیلد به‌روزرسانی بعدی را پیش از اعتماد به فایل تأیید کنید.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

جایگزین کنید، سپس هر دو نتیجه را اثبات کنید

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

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

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

کاری که بررسی نام هرگز نمی‌تواند انجام دهد

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

هرجا کنترل در سطح گواهی لازم است، از سازوکاری استفاده کنید که گواهی را نام می‌برد: ورودی‌های CRL، یا قلاب تأییدی که اثر انگشتی را که بهره‌بردار نگه می‌دارد بررسی می‌کند. هر دو هزینه نگهداری دارند و هر دو درباره شیئی که بررسی می‌کنند صادق‌اند. راهنمای OpenVPN 2.6 مستند می‌کند crl-verify و پذیرش مخصوص مشتری را به‌عنوان گزینه‌های جداگانه، به همین دلیل.

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