Трымайце каранёвы CA VPN па-за сеткай і выдавайце сертыфікаты

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

Што насамрэч правярае злучэнне

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

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

Пабудуйце корань на хосце, які ніколі не атрымлівае адрас

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

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

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

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext змяшчае basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign і authorityKeyIdentifier=keyid:always. Вярніце каранёвы ключ у сховішча перад паўторным падключэннем хосца подпісу. Калі корань павінен мець магчымасць адклікаць прамежкавы сертыфікат, падпішыце яго з дапамогай openssl ca -config root.cnf -extensions intermediate_ca супраць index.txt каранёвага ўзроўню замест openssl x509 -req, каб серыйны нумар быў запісаны; затым адпраўце атрыманы каранёвы спіс у профілі кліента, дзе файлавы crl-verify чытае яго пры запуску. Адпраўце кліентам пакет з абодвума сертыфікатамі CA; адзін канцавы сертыфікат не пройдзе праверку супраць кораня.

Выдавайце канцавыя сертыфікаты з прамежкавага CA, з базай даных

Подпіс з дапамогай openssl x509 -req працуе, пакуль вам не спатрэбіцца адкліканне, бо нішто не запісвае серыйны нумар. Выкарыстоўвайце openssl ca з першага сертыфіката, каб серыйны нумар, тэрмін дзеяння і стан адклікання жылі ў адной базе даных. Стварыце файлы базы даных адзін раз, затым накіруйце на іх канфігурацыю:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

Радок выкарыстання ключа разлічаны на ключ ECDSA; дадайце keyEncipherment для RSA. Дайце кожнаму кліенту ўласнае агульнае імя, бо OpenVPN ідэнтыфікуе злучэнне па гэтым полі, і два ноўтбукі з адным CN=vpn-client немагчыма адрозніць у журналах, у правілах client-config-dir або ў любой рассылцы для карыстальніка, і вы губляеце прыпісванне, якое робіць рашэнне аб адкліканні абароненым. Выдайце і праверце канцавы сертыфікат так:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

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

Публікуйце адкліканне, не будзячы корань

Кліенцкія сертыфікаты адклікае прамежкавы CA, а не корань. Каранёвы спіс мае значэнне, толькі калі прамежкавы CA спалены. Накіруйце сервер на прамежкавы спіс з дапамогай crl-verify. Файлавы CRL загружаецца пры запуску службы, таму перазагружайце пасля кожнай перагенерацыі; каталогавая форма чытае стан у момант злучэння і каштуе адзін файл на серыйны нумар.

Адклічце і перагенеруйце двума камандамі з той жа базы даных:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Затым сачыце за гадзіннікам. CRL мае поле наступнага абнаўлення, і калі гэтая дата мінае, асоба, якая правярае, адхіляе спіс замест таго, каб ігнараваць яго. Штомесячная перагенерацыя з default_crl_days = 30 пакідае запас; штогадовая — не. Больш кароткія тэрміны жыцця канцавых сертыфікатаў — больш надзейны кантроль, бо адкліканне дзейнічае толькі там, дзе звяртаюцца да спісу.

Праверце ланцуг, затым запішыце цырымонію

Узнавіце чатыры збоі перад тым, як даверыцца схеме. Праверце ланцуг з дапамогай openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Падключыцеся з пратэрмінаваным кліенцкім сертыфікатам і пераканайцеся, што сервер адмаўляе яго. Адклічце тэставы кліент, перазагрузіце і пераканайцеся, што спіс уступае ў сілу. Перасуньце гадзіннік хосца на дзень наперад, бо няправільны гадзіннік можа выдаць і адхіліць сертыфікаты, якія выглядаюць сапраўднымі ў іншым месцы.

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

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