CA با امضای متقابل: کلید یکی است، پیوند AKI نه

دو گواهی CA می‌توانند کلید عمومی یکسان و subject یکسان داشته باشند و همچنان قابل تعویض نباشند. یکی خودامضا است، دیگری توسط ریشه قدیمی به‌صورت متقابل امضا شده است، و نام‌های صادرکننده، شماره‌های سریال و امضاهایشان متفاوت است. برگ می‌تواند به‌طور مشخص از طریق Authority Key Identifier خود به یکی از آن‌ها پیوند بخورد. این پیوند تا زمانی که کلاینتی زنجیره اشتباه را انتخاب کند و handshake بدون دلیل آشکار شکست بخورد، نامرئی می‌ماند.

این پنج بررسی را به ترتیب انجام دهید: هر یک نوع متفاوتی از شکست را رد می‌کند.

بررسی 1: پیش از دست زدن به قالب، هر دو زنجیره را رسم کنید

مسیرها را بنویسید. جمعیت قدیمی به ریشه قدیمی A اعتماد دارد، که CA B را صادر کرد و آن برگ سرور را صادر کرد. جمعیت جدید مستقیماً به CA B خودامضا اعتماد دارد. هر دو گواهی B کلید و subject یکسان دارند، و دقیقاً به همین دلیل کسی که یک خط subject را می‌خواند یک CA می‌بیند جایی که کلاینت دو تا می‌بیند.

نسخه امضاشده متقابل نیز باید یک گواهی CA واقعی باشد، با basic constraints و key usage که امضا کردن را مجاز می‌کند.

بررسی 2: فیلدهای AKI را مقایسه کنید، نه فقط کلید را

نام صادرکننده برگ باید با subject مربوط به B مطابقت داشته باشد، و این بخش معمولاً برقرار است. Authority Key Identifier جایی است که دو نسخه از هم جدا می‌شوند، چون می‌تواند شناسه کلید، صادرکننده گواهی و شماره سریال را حمل کند. شناسه کلید با هر دو نسخه مطابقت دارد، زیرا کلید یکسان است. فیلدهای صادرکننده و شماره سریال دقیقاً با یکی مطابقت دارند، و به همین دلیل زنجیره‌ای که در برابر نسخه خودامضا ساخته می‌شود می‌تواند در برابر نسخه امضاشده متقابل شکست بخورد.

به‌جای حدس زدن، برگ را بررسی کنید: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

سپس هر دو نامزد را با openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" مقایسه کنید، و همان فرمان را در برابر نسخه خودامضا اجرا کنید.

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

بررسی 3: سیاست صدور را تغییر دهید، هرگز بایت‌های امضاشده را

افزونه‌ها درون امضا زندگی می‌کنند. افزودن، حذف یا ویرایش یکی از آن‌ها روی یک برگ موجود تعمیر نیست، بلکه گواهی دیگری است و به صدور دوباره نیاز دارد. تغییر به سیاست صدور تعلق دارد: authorityKeyIdentifier = keyid,issuer:always باعث می‌شود برگ‌های جدید پیوند مخصوص گواهی را حمل کنند، در حالی که keyid به‌تنهایی شکل سهل‌گیرانه‌تری را نگه می‌دارد که برای گذار عامدانه امضای متقابل مناسب است. پیش از امضای دسته بعدی تصمیم بگیرید کدام را PKI شما می‌خواهد.

ویرایش یک قالب مشترک همچنین هر گواهی آینده را تغییر می‌دهد، نه فقط سروری که پیش روی شماست.

بررسی 4: هر جمعیت اعتماد را جداگانه تأیید کنید

مسیر قدیمی و مسیر جدید را به‌صورت اجرای جداگانه آزمایش کنید. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem مسیر امضاشده متقابل را می‌آزماید، و همان فرمان با ریشه جدید و بدون فایل untrusted مسیر خودامضا را می‌آزماید. مخلوط کردن هر دو ریشه در یک بسته پنهان می‌کند که کدام زنجیره انتخاب شده است. سپس با کلاینت‌های واقعی تکرار کنید، چون یک backend VPN می‌تواند زنجیره‌ای را ترجیح دهد یا گواهی‌ای را تثبیت کند به روش‌هایی که openssl انجام نمی‌دهد.

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

بررسی 5: مسیر قدیمی را روی ساعت بازنشستگی نگه دارید

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

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