Само CSR не е регистрација: што треба да провери VPN CA

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

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

Барањето тврди име, но не го докажува

Прочитајте го барањето според тоа што навистина содржи: јавен клуч, subject избран од барателот и самопотпис врз двете. Ништо во таа структура не се повикува на вашиот инвентар, именикот на сметки или текот на одобрување. Subject како 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

Потоа тестирајте го пристапот, а не артефактот. Сертификатот воспоставува идентитет, а политиката сѐ уште одлучува до кои служби тој идентитет може да стигне. Проверете ги двете, бидејќи правилен артефакт со преширока политика исто така паѓа на ревизија. Потврдете дека клиентот се автентифицира и добива само предвидените рути или ресурси. Запишете што сте набљудувале, а не што требало профилот да прави.

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