CSR сам по себе не е регистрация: какво трябва да провери VPN CA

Заявката за подпис на сертификат носи публичен ключ и заявен субект, подписани със съответния частен ключ. Този подпис доказва, че заявителят притежава ключа. Той не доказва, че заявителят има право на името, устройството или ролята във VPN, които иска, и ако се отнасяме към него като че ли доказва, така тикетът на help desk става разрешение за достъп.

Два модела на регистрация си струва да се сравнят по това какво обвързват, а не по това кой протокол говорят.

Заявката заявява име, но не го доказва

Прочетете заявката за това, което действително съдържа: публичен ключ, субект, избран от заявителя, и самоподпис върху двете. Нищо в тази структура не препраща към вашия инвентар, каталога с акаунти или процеса на одобрение. Субект cn=finance-laptop е низ, който някой е написал. Докато процесът по издаване не провери този низ срещу запис, на който вярва, сертификатът е твърдение с прикачен подпис. Тази разлика е цялата причина процесът на регистрация да съществува.

Следствието има оперативно значение. Сертификатен орган никога не се нуждае от частния ключ на клиента, за да издаде сертификат, а работен процес, който го иска, е объркал подписването с депониране на ключове. Дръжте генерирането на крайната точка и изпращайте само публичната половина.

Сравнете моделите по това какво обвързват

Ръчното подписване обвързва каквото операторът помни да провери. Автоматизирана услуга за регистрация обвързва удостоверена заявка с решение, което услугата може да наложи, и RFC 7030 описва един такъв дизайн, при който клиентът се удостоверява, преди да бъде върнат сертификат. Разликата, която издържа на одит, не е автоматизацията; а дали проверката на самоличността се извършва в пътя на издаване или до него.

И двата модела все още трябва да отговорят на същите три въпроса. Кой пита, на кое устройство или роля и за колко време. Система за тикети, която записва отговорите, върши истинска работа; опашка, в която някой се взира в общо име, не върши, колкото и внимателно да се форматира сертификатът после.

Изберете модела според броя регистрации, които очаквате, и според смяната на устройства. Няколко сървъра годишно могат да минат ръчен преглед с писмен контролен списък. Парк от лаптопи не може.

Записвайте жизнения цикъл от първото издаване

Съхранявайте идентификатора на сертификата, собственика, предназначението, срока на валидност и пътя за премахване в момента на издаване, а не при първия инцидент. Предназначението принадлежи в самия сертификат чрез разширено използване на ключ, и записът трябва да съвпада с него. Сертификат, създаден за удостоверяване на клиент, не бива да е неразличим от такъв за сървър.

Планирайте подновяването и отмяната на изгубено устройство, преди да издадете десетия профил. Сертификат, споделен за цял отдел, превръща целенасоченото премахване в прекъсване и е много по-евтино да се преразгледа това решение сега, отколкото по време на петъчен инцидент.

Проверете издадения сертификат, после достъпа

След регистрацията прегледайте какво е издадено и потвърдете, че води до очаквания орган. Две команди покриват честите грешки: сертификат с грешно предназначение и верига, която работи само защото клиентът е конфигуриран да пренебрегва проверката.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

След това тествайте достъпа, а не артефакта. Сертификатът установява самоличност, а политиката все още решава кои услуги тази самоличност може да достигне. Проверете и двете, защото правилен артефакт с прекалено широка политика също се проваля на преглед. Потвърдете, че клиентът се удостоверява и получава само предвидените маршрути или ресурси. Запишете какво сте наблюдавали, а не какво е трябвало да прави профилът.

Профил, който работи по грешна причина, например съвпадащо общо име и липса на проверка на самоличността, ще продължи да работи, след като контролът, който сте смятали, че имате, бъде премахнат.