تمدید گواهی VPN بدون تغییر هویت آن
تمدید، نام‌ها، کاربردها و زنجیره‌ای را که مشتری از پیش به آن اعتماد دارد حفظ می‌کند. سه شرط تعیین می‌کند که این کار روتین است یا تغییری هماهنگ در اعتماد.
تمدید گواهی‌ای که هویت را تغییر می‌دهد تمدید نیست، مهاجرتی است با لباس بلیت نگهداری. مشتری یک نام، یک زنجیره و گاهی یک کلید مشخص را بررسی می‌کند، و هر سه می‌توانند بدون تغییر تاریخ انقضا تغییر کنند. پیش از درخواست جایگزین، بنویسید مشتری واقعاً چه چیزی را بررسی می‌کند: نام میزبان یا هویت همتا، کاربرد گواهی، سیاست کلیدها و زنجیره صادرکننده. تمدید بسته به اینکه جایگزین کدام‌یک از این‌ها را تغییر دهد، روتین یا هماهنگ است.
سه شرط شکل تمدید را تعیین می‌کند
سه شرط این‌هاست: آیا چیزی گواهی برگ را پین می‌کند، آیا زنجیره تغییر می‌کند، و چه کس دیگری نام را اعتبارسنجی می‌کند. از سمت مشتری پاسخ دهید نه از روی راحتی CA، چون مشتری همان چیزی است که ساعت سه بامداد شکست می‌خورد.
با بررسی گواهی‌ای که دارید شروع کنید. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName سوژه، صادرکننده، بازه اعتبار و نام‌هایی را که گواهی واقعاً برای آن‌ها معتبر است چاپ می‌کند. آن فیلد آخر مهم‌ترین است و بیشتر از همه فرض می‌شود: درخواست تمدیدی که SAN مورد اتکای مشتری را حذف کند، گواهی‌ای تولید می‌کند که از نظر فنی معتبر و از نظر عملکردی نادرست است. فهرست SAN را از گواهی قدیمی در درخواست کپی کنید نه اینکه آن را از حافظه دوباره تایپ کنید.
شرط یک: آیا چیزی گواهی برگ را پین می‌کند
اگر مشتریان به CA نگهداری‌شده اعتماد کنند و نام را اعتبارسنجی کنند، تمدید گواهی برگ با کلید جدید برای آن‌ها نامرئی است. اگر هر مشتری گواهی برگ، اثر انگشت آن یا کلید عمومی آن را پین کند، جایگزینی تغییری هماهنگ با گذار سخت است، چون پین قدیمی نمی‌تواند گواهی جدید را اعتبارسنجی کند.
پیش از سفارش هر چیزی مشخص کنید در کدام حالت هستید. پینی که هیچ‌کس مستندش نکرده هنوز پین است وقتی می‌شکند.
شرط دو: پین‌ها و زنجیره را مقایسه کنید
اثر انگشت‌ها پین را قابل بررسی می‌کنند: openssl x509 -noout -fingerprint -sha256 -in server.crt روی گواهی قدیمی و جدید، و openssl x509 -noout -pubkey برای مقایسه کلیدهای عمومی. اگر پیکربندی مشتری، یک پروفایل موبایل یا مخزن اعتماد دستگاهی هر یک از این دو مقدار را داشته باشد، شما یک پین دارید. پروفایل‌های VPN موبایل مخفیگاه رایجی هستند، چون پروفایل یک بار توزیع می‌شود و دیگر هرگز بررسی نمی‌شود.
اگر جایگزین از همان میانی بیاید و مشتری آن را از قبل دارد یا می‌تواند دریافت کند، در سمت اعتماد چیزی تغییر نمی‌کند. میانی جدید، صادرکننده متفاوت یا زنجیره‌ای که با ترتیب نادرست تحویل داده شود، همه تمدید را به تغییر اعتماد تبدیل می‌کنند، و خطا شبیه صادرکننده ناشناخته است نه گواهی منقضی.
زنجیره‌ای را که سرور واقعاً می‌فرستد با این بررسی کنید: openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts، و آن را به‌صورت محلی با این تأیید کنید: openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. انجام این کار پیش از تغییر، خط پایه‌ای برای مقایسه بعد از آن به شما می‌دهد.
شرط سه: چه کس دیگری نام را اعتبارسنجی می‌کند
یک متمرکزکننده VPN، یک متعادل‌کننده بار، یک کاوشگر پایش، یک یکپارچه‌سازی RADIUS یا SAML و یک پروفایل موبایل هر کدام می‌توانند نسخه خودشان از نام مورد انتظار یا لنگر اعتماد را نگه دارند. تمدید همان لحظه‌ای است که این نسخه‌ها واگرا می‌شوند، چون گواهی تغییر می‌کند و نسخه‌ها نه.
پیش از تغییر هر مصرف‌کننده‌ای را فهرست کنید و برای هر کدام تصمیم بگیرید که آیا به به‌روزرسانی نیاز دارد. آنکه فراموش کنید همان است که صدایتان می‌زند.
یک تله زمانی هم وجود دارد. شروع اعتبار را همانند انقضا بررسی کنید، چون گواهی‌ای که برای فعال‌سازی بعدی آماده شده اگر خیلی زود نصب شود رد می‌شود، و خطا شبیه مشکل ساعت است نه مشکل آماده‌سازی. openssl x509 -noout -dates روی فایل جدید پیش از استقرار، بررسی دو ثانیه‌ای است. یک مسیر بازیابی پشتیبانی‌شده و پیکربندی شناخته‌شده سالم را هم نگه دارید، تا تمدیدی که اشتباه پیش می‌رود با بازگرداندن گواهی و کلید قبلی قابل برگشت باشد.
استقرار دهید، با یک احراز هویت تازه تأیید کنید، سپس بازنشسته کنید
یک تونل برقرارشده بازتاب اعتبارسنجی‌ای است که هنگام ساخت آن رخ داده، بنابراین می‌تواند سالم به نظر برسد در حالی که هر اتصال جدید شکست می‌خورد. با یک احراز هویت تازه و با استفاده از نام سرویس واقعی که مشتریان به کار می‌برند آزمایش کنید.
بررسی سطح برنامه‌ای را که برای کاربر مهم است کامل کنید، و تحویل زنجیره را از دید مشتری تأیید کنید نه از دید سرور. بررسی‌های نام یا گواهی را برای بی‌صدا نگه داشتن گذار سرکوب نکنید؛ این کار یک مشکل سازگاری موقت را به مشکلی دائمی تبدیل می‌کند.
مواد منسوخ را فقط پس از تأیید استقرار بازنشسته کنید، و کلید به‌خطرافتاده را کاملاً موردی دیگر بدانید: تمدید به‌تنهایی چیزی را باطل نمی‌کند، پس هویت متأثر به فرایند ابطال و مدیریت نشست استقرار نیاز دارد. RFC 5280 قواعد گواهی و اعتبارسنجی مسیر را که زیربنای همه این‌هاست تعریف می‌کند. تمدید روتین گواهی برگ را از جایگزینی CA جدا نگه دارید، تا از مشتریان خواسته نشود بی‌دلیل به صادرکننده جدید اعتماد کنند.