چرا کپی کردن ca.key روی هر کلاینت VPN باعث از کار افتادن CA می‌شود
کلاینت گواهی عمومی CA را بررسی می‌کند؛ هرگز به کلیدی که امضا می‌کند نیاز ندارد. کپی کردن ca.key روی هر دستگاه، اختیار صدور را به هر کسی که یک نسخه بردارد می‌دهد.
جایی در دستورهای نصب، یک پوشه به‌طور کامل روی هر لپ‌تاپ کپی می‌شود، چون این کار آسان‌تر از تصمیم‌گیری درباره اینکه کدام فایل‌ها باید آنجا باشند بود. آن پوشه شامل ca.key است و همان لحظه که به دستگاه دومی می‌رسد، مرجع صدور گواهی دیگر یک مرجع نیست. اکنون هر دارنده می‌تواند هویت‌هایی صادر کند که بقیه شبکه به آن‌ها اعتماد خواهند کرد.
ارزش دارد این سردرگمی یک بار روشن شود، چون دو فایل شبیه هم به نظر می‌رسند و کارهای متضاد انجام می‌دهند.
ماده تأیید و ماده امضا
کلاینت به گواهی عمومی CA نیاز دارد تا بررسی کند گواهی‌ای که طرف مقابل ارائه می‌دهد توسط آن مرجع امضا شده است. این یک کار تأیید است و هیچ رازی لازم ندارد. امضای گواهی طرف مقابل کاری دیگر است که یک بار توسط کسی که CA را اداره می‌کند انجام می‌شود، با کلید خصوصی‌ای که هرگز از انبار محافظت‌شده‌اش خارج نمی‌شود. جدا نگه داشتن این دو کار تمام هدف فرستادن دو فایل است.
پس ca.crt به پروفایل تعلق دارد و ca.key به هیچ جای نزدیکی آن تعلق ندارد. نام فایل‌ها یک قرارداد است، نه تضمین، و به همین دلیل باید نوع را بررسی کرد و آن را از نام استنتاج نکرد.
معماری‌ای با CA میانی یا سرویس صدور برخط از این قاعده مستثنا نیست. این روش استاندارد دور نگه داشتن توانایی امضا از نقاط پایانی در حالی است که گواهی‌های دستگاه در مقیاس صادر می‌شوند.
کلاینت باید با کلید خودش چه چیزی را اثبات کند
هر دستگاه جفت کلید خودش و گواهی خودش را دریافت می‌کند، که یک بار توسط CA امضا می‌شود. کلاینت آن گواهی را ارائه می‌دهد و مالکیت کلید خصوصی متناظر را اثبات می‌کند، و سرور تصمیم می‌گیرد آن را بپذیرد یا نه. این همان هویتی است که با گم شدن یک لپ‌تاپ باطل می‌شود.
این تفاوت بیشتر پس از یک سرقت اهمیت دارد. با هویت‌های جداگانه برای هر دستگاه، یک کلاینت افشاشده با ابطال یا حذف طرف مقابل کنار گذاشته می‌شود و بقیه ناوگان به کار خود ادامه می‌دهد.
کلید مرجع نشت‌کرده را نمی‌توان این‌گونه مدیریت کرد. هر گواهی که تاکنون امضا کرده یا می‌توانست امضا کند مشکوک می‌شود، بنابراین پاسخ جایگزینی اعتماد است نه یک ابطال واحد. این یک پروژه است، نه یک تیکت.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
پیش از کپی کردن فایل به هر جایی، آن را بخوانید
دو فرمان بدون چاپ هیچ رازی به شما می‌گویند چه نوع شیئی در دست دارید. اولی موضوع و نشانه CA روی یک گواهی را نام می‌برد؛ دومی یک کلید را اعتبارسنجی می‌کند و نوع آن را گزارش می‌دهد. هر دو را روی فایل‌های بسته‌ای که در آستانه توزیع آن هستید اجرا کنید. هر چیزی که به‌عنوان کلید خصوصی معتبر شناخته شود به پوشه کلاینت تعلق ندارد.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
اگر فرمان دوم روی فایلی که در بسته کلاینت قرار دارد موفق شود، توقف کنید و بسته را در معرض نفوذ بدانید. خروجی‌ای که می‌گوید کلید معتبر است همچنین می‌گوید که آن کلید حاضر است، و همین حضور تمام مشکل است.
به جهت دیگر هم توجه کنید: پروفایل کلاینت به‌طور مشروع کلید خصوصی همان کلاینت را در خود دارد. حذف هر کلیدی که پیدا می‌کنید اتصال را قطع می‌کند بدون آنکه چیزی را بهتر کند، پس باید شیء پیش از حذف شناسایی شود.
مهار کلیدی که پیش‌تر توزیع کرده‌اید
فرض نکنید که حذف نسخه محلی افشا را برمی‌گرداند. هر کسی که فایل را داشته می‌توانسته کپی‌اش کرده باشد، و فرض ایمن این است که کرده است. فرایند رخداد اپراتور را دنبال کنید و لنگر اعتماد را جایگزین کنید، با صدور دوباره گواهی‌های دستگاه زیر یک CA تازه.
سپس بسته‌بندی‌ای را که مشکل را ساخت تغییر دهید. فهرست پوشه را با یک فهرست مجاز صریح از فایل‌ها بفرستید، کلید CA را روی ماشینی نگه دارید که هرگز به ناوگان کلاینت نمی‌پیوندد، و ثبت کنید کدام سامانه آن را نگه می‌دارد.
اگر مرجع باید مکرراً صادر کند، امضا را پشت یک سرویس یا یک مرجع میانی با دامنه محدود و اعتبار کوتاه ببرید. این‌گونه یک اشتباه آینده زیرمجموعه‌ای از صدور را افشا می‌کند نه ریشه اعتماد کل استقرار را.