Држете ја коренската 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 сертификати; само лисен сертификат нема да се провери против коренот.

Издавајте лисни сертификати од посредникот, со база на податоци

Потпишувањето со 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 или во било кое push по корисник, и ја губите припишуваноста што ја прави одлуката за отповикување одбранлива. Издадете и проверете лисен сертификат вака:

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 хостот: мала услуга што го автентицира барањето, го проверува заедничкото име против список на дозволени и враќа само сертификат. Запишете го секој сериски број; дневникот е единствената врска помеѓу сертификатот и лицето што го побарало.

Објавете отповикување без да го разбудите коренот

Клиентските сертификати ги отповикува посредникот, никогаш коренот. Коренската листа е важна само кога посредник е изгорен. Насочете го серверот кон посредничката листа со 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 има идно следно ажурирање и некој има календарски запис за секој рок во синџирот. Ако едно недостасува, поставката што изгледа офлајн е само недокументирана.