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

Екі дайджест сәйкес келуі керек. Содан кейін қосылып, сервер жазатын сәйкестіктің сіз рұқсат берген сәйкестік екенін растаңыз, тек туннель көтерілгенін емес. Егер кілт жоғалса немесе құрылғы ауыстырылса, жауап — күшін жою және жаңа құрылғыдан жаңа сұраныс; әкімшіден басқа жерден кілтті қайта жіберуді сұрау түпнұсқаны қалпына келтірмейді және сұранысты қауіпсіз еткен модельді тыныш бұзады.

Қатысты мақалалар