Ձեր VPN-ի արմատային CA-ն պահեք օֆլայն և միևնույն է թողարկեք վկայագրեր

Ձեր VPN-ը պատասխանում է միացումներին գիշերվա 3-ին, մինչդեռ դրա վկայագրերը ստորագրող մեքենան անջատված պառկած է դարակում։ Սերվերի վկայագիրը ստուգող հաճախորդը երբեք չի կապվում ձեր CA-ի հետ, ուստի CA-ն պետք չէ հասանելի լինել ոչ մի միացման համար։ Այն մասը, որը պլանավորում է պահանջում, այն օրն է, երբ վկայագիր պետք է թողարկել, թարմացնել կամ չեղարկել մինչ արմատային բանալին մնում է կողպված։

Ինչ է իրականում ստուգում միացումը

Երբ OpenVPN հաճախորդը միանում է, այն անցնում է ստորագրությունների շղթայով սերվերի տերևային վկայագրից վերև մինչև CA վկայագիր, որին արդեն վստահում է, ստուգում է վավերականության պատուհանը և, եթե պրոֆիլն այդպես է ասում, դիմում է չեղարկման ցանկին։ Այն երբեք չի փնտրում ձեր արմատային CA-ն։ Սերվերը հայելային գործողություն է կատարում հաճախորդի վկայագրերի համար։ Միացման պահին առկա են միայն տերևը, միջանկյալը և ավելի վաղ տարածված վստահության փաթեթը։

Իրականում ձախողվում է երեքից մեկը՝ ստորագրման բանալին թողարկման պահին հասանելի չէ, չեղարկման ցանկը հնացել է, կամ հաճախորդի վստահության փաթեթն ավելի հին է, քան սերվերի ներկայացրած շղթան։ Առաջինը գործընթացի խնդիր է, մյուս երկուսը՝ բաշխման։ Դրանցից ոչ մեկը չի պահանջում, որ արմատային բանալին լինի առցանց, և կառավարվող VPN ծառայությունը, որը թունելի նույնականացման համար մասնավոր վկայագիր է պահանջում, միայն ստորագրման լիազորությունը տեղափոխում է մատակարարի մոտ։ Azure point-to-site-ը հակառակ է աշխատում՝ բեռնում եք արմատային վկայագիր, և դրա տակ ստորագրված վկայագրերը վստահելի են համարվում, ուստի հարցրեք ով է ստորագրում, ով է ստուգում և ինչպես է վկայագիրը վաղաժամ հետ կանչվում։

Կառուցեք արմատը հոսթի վրա, որը երբեք հասցե չի ստանում

Օֆլայն արմատը հազվադեպ է օգտագործվում՝ միջանկյալ 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 բանալի, RSA-ի համար ավելացրեք keyEncipherment։ Տվեք յուրաքանչյուր հաճախորդի իր ընդհանուր անունը, որովհետև 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-ն ունի ապագա հաջորդ թարմացում, և ինչ-որ մեկը օրացույցի գրառում ունի շղթայի յուրաքանչյուր ժամկետի համար։ Եթե մեկը բացակայում է, օֆլայն տեսք ունեցող կարգավորումը պարզապես չփաստաթղթավորված է։