Як згенераваць ключ кліента VPN і падаць CSR на подпіс

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

Крок 1: згенеруйце ключ там, дзе ён будзе жыць

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

Праграмны працэс выглядае так, ключ і запыт ствараюцца ў адной сесіі:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

Крок 2: змясціце асобу ў запыт, а не ў пошту

Вызначце, што менавіта аўтэнтыфікуе VPN, перш чым ствараць запыт, бо гэты адказ належыць унутр CSR. OpenVPN традыцыйна прывязвае асобу кліента да агульнага імя сертыфіката, а такія інструменты, як strongSwan, супастаўляюць радок асобы з суб'ектам або альтэрнатыўным імем суб'екта. Ліст, які кажа, што мяне завуць alice, не з'яўляецца доказам, а запыт, у суб'екце якога сказана тое ж самае, ледзь лепшы.

Дадайце альтэрнатыўнае імя суб'екта, калі ваш правяральнік яго правярае, бо сучаснае супастаўленне часта ігнаруе стары CN:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Трымайце CN кароткім, стабільным і прывязаным да ўліковага запісу, а не да мадэлі ноўтбука. Імя, якое змяшчае серыйны нумар прылады карыстальніка, — гэта праблема падтрымкі, якая чакае першай замены абсталявання.

Крок 3: праверце запыт, перш чым падпісваць яго

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

Механічная частка — гэта адна каманда, і яна павінна вывесці вынік праверкі разам з суб'ектам:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

Крок 4: дазвольце, затым падпішыце з явнымі пашырэннямі

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

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

Крок 5: усталюйце яго побач з адпаведным ключом і дакажыце пару

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

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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