ورودهای جدید VPN در حالی که گواهی‌ها معتبرند ناموفق می‌شوند: CRL را بررسی کنید
گواهی معتبر کارخواه و فهرست ابطال منقضی‌شده دو شیء متفاوت روی دو ساعت متفاوت‌اند. فهرستی را که سرور بارگذاری می‌کند بخوانید، سپس آن را از نو تولید کنید.
گواهی‌هایی که هنوز ماه‌ها از آن‌ها مانده و ورودهایی که بی‌درنگ ناموفق می‌شوند به دو شیء متفاوت با دو ساعت متفاوت اشاره می‌کنند. سرور اتصال‌ها را رد می‌کند چون فهرست گواهی‌های ابطال‌شده‌ای که به آن رجوع می‌کند از تاریخ انقضای خودش گذشته است، نه چون گواهی‌های کاربران کهنه شده‌اند. تمدید یک گواهی کاربر برای آن فهرست کاری نمی‌کند.
جدا کردن این دو زمان‌بندی تمام تشخیص است و تغییر می‌دهد که اصلاح باید چه شکلی باشد.
دو ساعت، و تنها یکی از آن‌ها گواهی است
هر گواهی یک پنجره اعتبار دارد. فهرست ابطال گواهی پنجره خودش را دارد، به‌همراه صادرکننده و امضا، و بررسی‌کنندگان از اعتماد به فهرستی که زمان به‌روزرسانی بعدی‌اش گذشته باشد خودداری می‌کنند. وقتی این اتفاق می‌افتد، کارخواه گواهی کاملاً معتبری ارائه می‌دهد و سرور باز هم اتصال را با پیامی درباره آن فهرست قطع می‌کند. کاربران آن پیام را «گواهی منقضی شده است» می‌خوانند و همین درخواست تمدید را به جای اشتباه می‌فرستد.
این دو شیء صاحبان متفاوتی هم دارند: گواهی از مرجع صدور گواهی می‌آید که آن را صادر کرده است، در حالی که فهرست بر اساس زمان‌بندی توسط کسی که آن مرجع را اداره می‌کند تولید می‌شود. کاربر نمی‌تواند آن را تازه کند و صدور دوباره گواهی‌ها نمی‌تواند آن را تمدید کند.
فهرستی را بخوانید که سرویس واقعاً بارگذاری می‌کند
از پیکربندی در حال اجرا شروع کنید، نه از فایلی که انتظار دارید. مسیر crl-verify ممکن است مطلق باشد، نسبت به پروفایل، یا نسخه‌ای که در یک ایمیج تعبیه شده است، و بررسی‌کننده همان نسخه را می‌خواند. آن را در جای خود با openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate بررسی کنید و تاریخ‌ها را با ساعت سرور مقایسه کنید.
سپس تأیید کنید که فایل واقعاً همان فایل در حال استفاده است: امضای آن را با openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout بررسی کنید، که به‌جای چاپ بی‌صدای فیلدها، نتیجه بررسی را گزارش می‌دهد. فهرستی که مرجع صدور دیگری آن را امضا کرده، یا نسخه کهنه‌ای که در پوشه دومی جا مانده، دقیقاً مثل فهرست منقضی شکست می‌خورد.
از پایگاه داده ابطال دوباره تولید کنید، نه از صفر
فهرست جدید باید از پایگاه داده ابطال کنونی همان مرجع صدور، از طریق فرایند امضای تأییدشده بیاید. تولید فهرست خالی، یا تولید دوباره از نسخه پشتیبان قدیمی نمایه، بی‌صدا ابطال هر هویتی را که پس از آن نسخه پشتیبان افزوده شده لغو می‌کند. این یک قطعی ورود را به پس‌رفت امنیتی تبدیل می‌کند و کسی متوجه نمی‌شود چون نشانه از بین می‌رود.
مرحله تولید را همراه با بقیه ابزارهای مرجع صدور تحت کنترل نسخه نگه دارید تا فاصله زمانی و کلید امضا مستند باشند نه به‌خاطر سپرده شوند. یک مدخل در دفترچه عملیات که فرمان، امضاکننده و مقصد انتشار را نام ببرد کافی است. آن‌گاه هر کسی در کشیک می‌تواند بدون حدس زدن اینکه کدام فایل نمایه معتبر است دوباره تولید کند. شماره سریال فهرست و زمان به‌روزرسانی بعدی را همراه با سابقه استقرار ذخیره کنید.
جایی مستقر کنید که بررسی‌کننده نگاه می‌کند
فهرست جدید را به مسیری کپی کنید که سرویس می‌خواند، مالکیت و مجوز را طوری تنظیم کنید که حساب سرویس بتواند آن را بخواند ولی دیگران نتوانند، و بر اساس رفتار مستند، دوباره بارگذاری یا راه‌اندازی مجدد کنید. اگر سرویس‌دهنده فهرست را در هنگام راه‌اندازی در حافظه پنهان نگه می‌دارد، جایگزینی فایل بدون بارگذاری دوباره چیزی را که فرایند در حال اجرا متوجه شود تغییر نمی‌دهد. مُهر زمانی‌ای را که فرایند پس از بارگذاری دوباره گزارش می‌کند تأیید کنید.
اگر چند سرویس کارخواه‌ها را بررسی می‌کنند، در هر یک از آن‌ها مستقر کنید. به‌روزرسانی یک نقطه پایانی و رها کردن دیگری با نسخه قدیمی، خطایی پدید می‌آورد که فقط برای کاربرانی ظاهر می‌شود که به دومی می‌رسند. فهرست کوتاهی از این نقاط پایانی را در همان دفترچه عملیات نگه دارید. پس از استقرار، تاریخ فهرست گزارش‌شده هر یک را بررسی کنید نه اینکه فرض کنید نسخه رسیده است.
مهلت بعدی را پیش از فرا رسیدن قابل مشاهده کنید
فاصله انتشار طولانی‌تر بسامد این حادثه را کم می‌کند بدون اینکه فرایندی بسازد. فاصله را از سیاست اپراتور انتخاب کنید، سپس روی فیلد به‌روزرسانی بعدی فهرست مستقرشده با زمان پیشروی کافی برای تولید دوباره و استقرار هشدار بگذارید. روی نسخه مستقرشده هشدار بگذارید، نه روی میزبان مرجع صدور، چون نسخه مستقرشده همان چیزی است که شکست می‌خورد.
پس از استقرار، هر دو جهت را بررسی کنید: کاربر مجاز متصل می‌شود، و هویت ابطال‌شده شناخته‌شده باز هم شکست می‌خورد. بررسی دوم همانی است که تولید دوباره ناقص را می‌گیرد، و تنها یک فرمان در برابر پروفایل آزمایشی می‌خواهد که دقیقاً برای همین منظور نگه می‌دارید.