Чому копіювання 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 на машині, яка ніколи не входить до парку клієнтів, і записуйте, яка система його зберігає.
Якщо центр має випускати часто, перенесіть підпис за службу або проміжний центр з вузьким охопленням і коротким строком дії. Тоді майбутня помилка розкриє частину випуску, а не корінь довіри всього розгортання.