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

Хоёр дижест тохирох ёстой. Дараа нь холбогдож, серверийн бүртгэсэн таних тэмдэг таны зөвшөөрсөн нь мөн эсэхийг баталгаажуул, зөвхөн туннель боссон гэсэн үг биш. Хэрэв түлхүүр алга болвол эсвэл төхөөрөмж солигдвол хариулт нь хүчингүй болгох ба шинэ төхөөрөмжөөс шинэ хүсэлт юм; администратороос өөр газраас түлхүүрийг буцааж илгээхийг хүсэх нь эх хувийг сэргээхгүй бөгөөд хүсэлтийг аюулгүй болгосон загварыг чимээгүй эвддэг.

Холбоотой нийтлэлүүд