Дръжте кореновия 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 има бъдещо следващо обновяване и някой притежава календарен запис за всеки срок във веригата. Ако липсва едно, настройката, която изглежда офлайн, е просто недокументирана.