وقتی مرجع صدور گواهی VPN را جایگزین می‌کنید چه اتفاقی می‌افتد

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

یک جایگزینی، دو تغییر جداگانه

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

بیشتر استقرارهای VPN در هر دو جهت اعتبارسنجی می‌کنند. کلاینت گواهی دروازه را احراز هویت می‌کند و دروازه گواهی کلاینت را. چرخشی که فقط بستهٔ کلاینت را به‌روز می‌کند باعث می‌شود سرور هر کلاینتی را که هنوز هویتی از CA قدیمی ارائه می‌دهد رد کند، و برعکس آن هم به همان اندازه رایج است. ابتدا نقاط اعمال را فهرست کنید: انبارهای اعتماد کلاینت‌ها، فایل ca دروازه، هر پروکسی‌ای که TLS را پیش از آن پایان می‌دهد، و کاوشی که نقطهٔ پایانی را از بیرون بررسی می‌کند.

اعتبارسنج چه چیزی را به چه ترتیبی بررسی می‌کند

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

برای تکرار آن مسیر به‌صورت برون‌خط، -CAfile را به همان بسته‌ای اشاره دهید که مستقر می‌کنید، نه به انبار سیستم. در غیر این صورت میزبان را آزمایش می‌کنید، نه تغییر را:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

آن فرمان فقط در برابر یک شنوندهٔ سادهٔ TLS کار می‌کند، مانند صفحهٔ مدیریت HTTPS دروازه؛ کانال کنترل OpenVPN پیش از TLS می‌آید، پس s_client نمی‌تواند دست‌دهی تونل را بررسی کند.

قواعد ساخت مسیر که پشت این خطاها هستند در RFC 5280 بخش 6 آمده‌اند. آن‌ها شکست‌هایی را توضیح می‌دهند که در غیر این صورت دلبخواه به نظر می‌رسند: یک واسطهٔ منقضی که کسی به یاد نداشت، گواهی‌ای که کاربرد کلیدش امضا را ممنوع می‌کند، یا محدودیت نامی که میزبان آزمون شما را حذف می‌کند.

چرا تونل قدیمی به کار خود ادامه می‌دهد

TLS و OpenVPN هر دو یک نشست برقرارشده را پس از پایان دست‌دهی زنده نگه می‌دارند. هیچ چیز گواهی همتا را به ازای هر بسته دوباره اعتبارسنجی نمی‌کند، بنابراین کلاینتی که پیش از تغییر وصل شده تا زمانی که دوباره مذاکره کند، دوباره متصل شود یا تونل بیفتد، ترافیک را عبور می‌دهد. همین شکاف باعث می‌شود جایگزینی CA یک ساعت خوب به نظر برسد و بعد در بدترین لحظه شکست بخورد: لپ‌تاپ از خواب بیدار می‌شود، نگاشت NAT منقضی می‌شود، دروازه دوباره راه‌اندازی می‌شود.

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

لایهٔ کلید ایستا را از این جدا نگه دارید. tls-auth یک HMAC به کانال کنترل می‌افزاید، tls-crypt آن را رمزگذاری و احراز هویت می‌کند، و هیچ‌کدام مواد گواهی حمل نمی‌کنند، پس چرخش هر یک تغییری جداگانه با حالت شکست خودش است. استقرارهایی که این دو را با هم اشتباه می‌گیرند به کلاینتی می‌رسند که کلید ایستایش درست است، گواهی‌اش کهنه و پیام خطایش هیچ‌کدام را ذکر نمی‌کند.

تلهٔ استفادهٔ دوباره از نام موضوع

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

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

چرخشی که شبکه را از کار نمی‌اندازد

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

اگر به این ترتیب انجام شود، هر گام برگشت‌پذیر است. شکستی که از آن اجتناب می‌کنید سوئیچ هم‌زمان است: کلاینتی که به‌روزرسانی بسته را از دست داده به دروازه‌ای می‌رسد که لنگر قدیمی را بازنشسته کرده، دست‌دهی می‌میرد، و هیچ‌یک از دو گزارش نمی‌گوید کدام سو کهنه است.

در جهت مخالف بازنشسته کنید. هر هویتی را که باید بماند دوباره صادر کنید، تأیید کنید هر یک زنجیرهٔ جدید را ارائه می‌دهد، سپس لنگر قدیمی را از بسته‌ها بردارید. کلید خصوصی CA قدیمی را از سرویس خارج کنید، چون صادرکننده‌ای که هنوز می‌تواند امضا کند یعنی چرخش تمام نشده است. گواهی‌ها و سوابق صدور را برای حسابرسی نگه دارید. صادرکنندهٔ ازدست‌رفته به همان اعتماد بازمی‌گردد؛ یک افشا هویت‌های تازه لازم دارد و بازگشتی به لنگر قدیمی ندارد.

نتیجه را تأیید کنید، نه فهرست فایل‌ها را

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

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

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