Како да генерирате клуч за 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

Двете хеш-вредности мора да се совпаѓаат. Потоа поврзете се и потврдете дека идентитетот што серверот го запишува е оној што сте го овластиле, а не само тоа што тунелот се крена. Ако клучот се загуби или уредот се замени, одговорот е отповикување плус ново барање од новиот уред; барањето од администраторот да врати клуч од друго место не го враќа оригиналот и тивко го крши моделот што барањето го правел безбедно.