Адзін CSR — яшчэ не рэгістрацыя: што павінен праверыць цэнтр сертыфікатаў VPN

Запыт на подпіс сертыфіката змяшчае публічны ключ і запытаны суб'ект, падпісаныя адпаведным прыватным ключом. Гэты подпіс даказвае, што запытнік валодае ключом. Ён не даказвае, што запытнік мае права на імя, прыладу ці ролю VPN, якую просіць, і калі абыходзіцца з ім так, нібы ён гэта даказвае, заяўка службы падтрымкі ператвараецца ў выдачу доступу.

Дзве мадэлі рэгістрацыі варта параўноўваць па тым, што яны звязваюць, а не па тым, на якой пратаколе яны гавораць.

Запыт заяўляе імя, але не даказвае яго

Чытайце запыт па тым, што ён насамрэч змяшчае: публічны ключ, суб'ект, абраны запытнікам, і ўласны подпіс над абодвума. Нішто ў гэтай структуры не спасылаецца на ваш інвентар, каталог уліковых запісаў або працэс зацвярджэння. Суб'ект 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

Затым праверце доступ, а не артэфакт. Сертыфікат усталёўвае асобу, а палітыка ўсё яшчэ вырашае, якія службы гэтая асоба можа дасягнуць. Праверце абодва, бо правільны артэфакт разам з занадта шырокай палітыкай усё адно не пройдзе разгляд. Пераканайцеся, што кліент аўтэнтыфікуецца і атрымлівае толькі прызначаныя маршруты ці рэсурсы. Запішыце тое, што вы назіралі, а не тое, што профіль павінен быў рабіць.

Профіль, які працуе з няправільнай прычыны, напрыклад супадальнае агульнае імя і адсутнасць праверкі асобы, працягне працаваць пасля таго, як кантроль, які вы думалі, што маеце, будзе зняты.