Как да генерирате ключ за VPN клиент и да подадете CSR за подписване

Пазете частния ключ при клиента и изпращайте само заявката. Проверете 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

Двете хеш стойности трябва да съвпадат. След това се свържете и потвърдете, че самоличността, която сървърът записва, е тази, която сте оторизирали, а не просто че тунелът е тръгнал. Ако ключът е загубен или устройството е подменено, отговорът е отзоваване плюс нова заявка от новото устройство; молбата администраторът да изпрати ключ от другаде не възстановява оригинала и тихо разваля модела, който е правил заявката безопасна.

Подобни статии