Выкарыстоўвайце існуючы карпаратыўны CA для піраў OpenVPN

Нішто ў OpenVPN не патрабуе, каб сертыфікат паходзіў з Easy-RSA, а парк, які ўжо мае арганізацыйную PKI, звычайна не павінен будаваць другую. Сапраўдная праца — не выбар інструмента, а рашэнне пра тое, што азначаюць выдадзеныя ідэнтычнасці, якіх піраў прымае тунель і як абнаўленне і адкліканне даходзяць да правяральніка. Прайдзіце пяць крокаў ніжэй па парадку, бо позні крок не можа выправіць рашэнне пра ролю, прынятае ў першым.

Выдайце дзве ролі замест адной агульнай ідэнтычнасці

Кожнаму піру патрэбны ўласны сертыфікат і адпаведны прыватны ключ. Папрасіце каманду PKI пра ідэнтычнасць сервера з прызначэннем сервера і асобныя ідэнтычнасці кліентаў з прызначэннем кліента, каб тунель мог адрозніць іх падчас рукапаціску.

Супрацьстойце кароткім шляхам, што з'яўляюцца пад ціскам тэрмінаў. Скапіяваны на ноўтбукі ключ вэб-сервера сцірае адрозненне, на якім трымаецца праверка ролі, а ключ подпісу CA, усталяваны на канчатковым пункце VPN, ператварае адзін скампраметаваны хост у скампраметаваную іерархію. Пакет PKCS12 можа несці ключ канчатковага пункта і яго ланцуг, але ён ніколі не дае дазволу паўторна выкарыстоўваць гэтую ідэнтычнасць у іншай ролі.

Падключыце ўваходы даверу на кожным баку

Кліенту і серверу патрэбны якар даверу, уласная ідэнтычнасць і яўнае чаканне ролі. Фрагмент кліента, які ўказвае ўсе тры, выглядае так.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Бок сервера люструе гэта з remote-cert-tls client і ўласным сертыфікатам, і менавіта гэта не дазваляе прыняць кліенцкі сертыфікат за сервер. Праверка імя — асобнае рашэнне ад праверкі ролі. Чытайце разгорнутую канфігурацыю, каб убачыць, якое поле параўноўваецца, замест таго каб меркаваць пра супадзенне імя хоста ў стылі браўзера. Абодва бакі таксама павінны яўна ўказваць, якому эмітэнту яны давяраюць, бо агульны шлях да файла праз парк — не тое ж самае, што агульная палітыка.

Перадавайце прамежкавыя сертыфікаты, не пашыраючы давер

Два бакі не абавязаны дзяліць адзін ланцуг эмісіі. Калі пір прадстаўляе сертыфікат, падпісаны прамежкавым, правяральнаму боку патрэбны гэты прамежкавы сертыфікат даступным, і OpenVPN адрознівае ўваход якара даверу ад дадатковых сертыфікатаў, якія выкарыстоўваюцца для завяршэння лакальна прадстаўленага ланцуга. Даведнік па параметрах TLS у OpenVPN 2.6 апісвае абое.

Прамежкавы CA сам па сабе не праблема, а шырокі карпаратыўны корань, кінуты ў набор даверу, — праблема. Чым шырэйшы якар, тым больш сертыфікатаў праходзіць тэст ланцуга, і праверка ролі не ператварае гэта ў спіс аўтарызаваных супрацоўнікаў. Звужвайце якар да эмітэнта, які фактычна падпісвае ідэнтычнасці VPN, дзе іерархія гэта дазваляе. Калі не дазваляе, задокументуйце шырэйшы якар як наўмысна прынятую рызыку, а не пакідайце яго няяўным.

Дагаварыцеся з камандай PKI пра тое, як абнаўленне і адкліканне даходзяць да правяральнікаў VPN, уключаючы тое, якія эмітэнты важныя і хто публікуе спіс. Пункт размеркавання CRL, убудаваны ў сертыфікат, — гэта інструкцыя, а не доказ таго, што нешта яго загрузіла.

Вырашыце, як адкліканне фактычна прыходзіць

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

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

Дакажыце прыняццё рэальным кліентам

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

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