Зошто копирањето на ca.key на секој VPN клиент ја крши CA

Некаде во упатството за поставување, цел директориум се копира целосно на секој преносен компјутер бидејќи тоа беше полесно отколку да се одлучи кои датотеки припаѓаат таму. Тој директориум содржи ca.key, и во моментот кога ќе стигне до втор уред, сертификациското тело престанува да биде тело. Секој сопственик сега може да издава идентитети на кои ќе им верува остатокот од мрежата.

Вреди оваа забуна да се разјасни еднаш, бидејќи двете датотеки изгледаат слично, а прават спротивни работи.

Материјал за проверка и материјал за потпишување

На клиентот му е потребен јавниот сертификат на CA за да провери дека сертификатот што го претставува другата страна е потпишан од тоа тело. Тоа е задача за проверка и воопшто не бара тајна. Потпишувањето на сертификат на другата страна е друга задача, која еднаш ја извршува тој што управува со CA, со приватниот клуч што никогаш не го напушта неговото заштитено складиште. Одвојувањето на овие две задачи е целата смисла на испраќањето две датотеки.

Затоа ca.crt припаѓа на профилот, а ca.key не припаѓа никаде близу до него. Имињата на датотеките се конвенција, а не гаранција, затоа типот мора да се прегледа, а не да се заклучи од името.

Архитектура со посредна CA или онлајн услуга за издавање не е исклучок. Тоа е стандардниот начин да се држи способноста за потпишување далеку од крајните точки додека сертификатите на уредите се издаваат во голем обем.

Што треба клиентот да докаже со својот клуч

Секој уред добива свој пар клучеви и свој сертификат, еднаш потпишан од CA. Клиентот го претставува тој сертификат и докажува дека го поседува соодветниот приватен клуч, а серверот одлучува дали да го прифати. Тоа е идентитетот што се отповикува кога ќе се загуби преносен компјутер.

Контрастот е најважен по кражба. Со идентитети по уред, еден изложен клиент се отстранува со отповикување или со отстранување на другата страна, а остатокот од флотата продолжува да работи.

Протечен клуч на тело не може да се третира така. Секој сертификат што некогаш го потпишал или можел да го потпише станува сомнителен, затоа одговорот е замена на довербата, а не едно отповикување. Тоа е проект, не барање.

Прочитајте датотека пред да ја копирате некаде

Две наредби ви кажуваат каков вид објект држите в раце без да испечатат никаква тајна. Првата го наведува субјектот и знамето CA на сертификат; втората го валидира клучот и го известува неговиот тип. Извршете ги двете врз датотеките во пакетот што ќе го дистрибуирате. Сето она што се валидира како приватен клуч не припаѓа во директориум на клиент.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Ако втората наредба успее на датотека што се наоѓа во клиентски пакет, запрете и третирајте го пакетот како компромитиран. Излезот што вели дека клучот е валиден исто така вели дека тој е присутен, а присутноста е целиот проблем.

Обрнете внимание и на спротивниот правец: клиентски профил законски го содржи сопствениот приватен клуч на тој клиент. Бришењето на секој најден клуч ја прекинува врската без да подобри ништо, затоа објектот мора да се идентификува пред да се отстрани.

Ставање под контрола на клуч што веќе сте го дистрибуирале

Не претпоставувајте дека бришењето на локалната копија ја враќа изложеноста. Секој што ја имал датотеката можел да ја копира, а безбедната претпоставка е дека ја копирал. Следете ја постапката за инциденти на операторот и заменете го сидрото на довербата, преиздавајќи ги сертификатите на уредите под нова CA.

Потоа сменете го пакувањето што го создаде проблемот. Испратете список на директориумот со јасен список на дозволени датотеки, држете го клучот на CA на машина што никогаш не се приклучува на клиентската флота, и запишете кој систем го чува.

Ако телото мора често да издава, преместете го потпишувањето зад услуга или посредно тело со тесен опсег и кратко важење. Така идната грешка ќе изложи дел од издавањето, а не коренот на довербата на целото распоредување.