د OpenVPN سیالانو لپاره خپل موجود شرکت CA وکاروئ

OpenVPN کې هیڅ هم نه غواړي چې تصدیق د Easy-RSA څخه راشي، او هغه فلیټ چې لا دمخه سازماني PKI لري معمولاً باید دویم جوړ نکړي۔ ریښتینی کار د وسیلې غوره کول نه دي، بلکې دا پرېکړه ده چې صادر شوي هویتونه څه معنا لري، تونل کوم سیالان مني، او نوی کول او لغوه کول څنګه تایید کوونکي ته رسیږي۔ لاندې پنځه ګامونه په ترتیب سره بشپړ کړئ، ځکه چې وروستی ګام نشي کولی په لومړي کې شوې د رول پرېکړه سمه کړي۔

د یو ګډ هویت پر ځای دوه رولونه صادر کړئ

هر سیال خپل تصدیق او ورته سم خصوصي کیلي ته اړتیا لري۔ د PKI ټیم څخه د سرور کارونې سره سرور هویت او د مراجع کارونې سره جلا مراجع هویتونه وغواړئ، ترڅو تونل د لاس ورکولو په وخت کې دواړه سره توپیر کړي۔

د وخت د محدودیت تر فشار لاندې راڅرګندېدونکو لنډو لارو مخه ونیسئ۔ د ویب سرور کیلي کمپیوټرونو ته کاپي کول هغه توپیر پاکوي چې د رول تصدیق پرې ولاړ دی، او د VPN پای نقطې ته نصب شوې CA لاسلیک کیلي یو زیانمن شوی کوربه زیانمن شوي سلسله مراتب ته بدلوي۔ د PKCS12 بنډل کولی شي د پای نقطې کیلي او هغې سلسله ولیږدوي، مګر هیڅکله د دې هویت په بل رول کې د بیا کارولو اجازه نه ورکوي۔

په هر اړخ کې د باور ننوتنې ونښلوئ

مراجع او سرور هر یو د باور لنگر، خپل هویت او روښانه د رول تمه ته اړتیا لري۔ د مراجع هغه ټوټه چې درېواړه یادوي داسې ښکاري۔

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

د سرور اړخ دا د remote-cert-tls client او خپل تصدیق سره انځوروي، او همدا دي چې د مراجع تصدیق د سرور په توګه منل کېدو مخه نیسي۔ د نوم تصدیق د رول تصدیق څخه جلا پرېکړه ده۔ د براوزر په سټایل د کوربه نوم د سمون د انګیرنې پر ځای دې چې کوم فیلیډ پرتله کېږي هغه لیدلو لپاره ځای پرځای شوی ترتیب ولولئ۔ دواړه اړخونه باید روښانه کړي چې د کوم صادرونکي باور لري، ځکه چې په ټول فلیټ کې ګډ د فایل لاره د ګډې پالیسۍ سره یو شان نه ده۔

پرته له دې چې باور پراخ کړئ منځني تصدیقونه ورسوئ

دواړه اړخونه اړ نه دي چې یوه صادرولو سلسله شریکه کړي۔ کله چې سیال د منځني لخوا لاسلیک شوی تصدیق وړاندې کوي، تایید کوونکي اړخ ته هغه منځنی شتون ته اړتیا لري، او OpenVPN د باور لنگر ننوتنه د هغو اضافي تصدیقونو څخه توپیروي چې د ځایي وړاندې شوې سلسلې بشپړولو لپاره کارېږي۔ د OpenVPN 2.6 TLS انتخابونو حواله دواړه مستندوي۔

منځنی CA پخپله ستونزه نه ده، مګر په باور بنډل کې اچول شوی پراخ شرکت ریښه ستونزه ده۔ هرڅومره چې لنگر پراخ وي، هومره ډیر تصدیقونه د سلسلې ازموینه پاس کوي، او د رول تصدیق هغه د مجاز کارمندانو لیست نه جوړوي۔ چېرې چې سلسله مراتب اجازه ورکوي لنگر هغه صادرونکي ته محدود کړئ چې واقعاً د VPN هویتونو لاسلیک کوي۔ که اجازه نه ورکوي، پراخ لنگر د پټ پریښودو پر ځای په قصد سره منل شوې خطر په توګه مستند کړئ۔

د PKI ټیم سره موافقه وکړئ چې نوی کول او لغوه کول VPN تایید کوونکو ته څنګه رسیږي، په دې کې چې کوم صادرونکي مهم دي او لیست څوک خپروي۔ په تصدیق کې ځای پرځای شوی CRL ویش ټکی لارښوونه ده، د دې ثبوت نه چې چا هغه راوړی۔

پرېکړه وکړئ چې لغوه کول واقعاً څنګه راځي

crl-verify تایید کوونکي ته اړ کوي چې فایل یا پای نقطې ته مراجعه وکړي، او دا ترتیب مالک او د تازه کولو لارې ته اړتیا لري۔ هغه لیست چې د ځای پرځای کولو په وخت کې یو ځل کاپي شو د لومړي ځل لپاره د تصدیق لغوه کېدو پر مهال په خاموشۍ ستاسو ساتنه بندوي۔

د تمه شوې خپریدو وخت ولیکئ او د هغه تصدیق سره یې ازموئ چې لغوه کولو ته تیار یاست۔ که لیست په VPN کوربه کې تازه نشي کیدلی، بدیل لنډ د اعتبار موده او هغه نوی کول بهیر دی چې واقعاً ځي، نه دا انګیرنه چې لغوه کول کار کوي ځکه URL شته۔

د ریښتیني مراجع سره مننه ثابته کړئ

هغه مراجع ونښلوئ چې باید اجازه ولري او په لاګ کې د خبرو شوي تصدیق تفصیلات تایید کړئ۔ بیا هغه قضیې هڅه کړئ چې باید ناکامې شي: د سرور په توګه وړاندې شوی مراجع تصدیق، د باور لنگر څخه بهر د صادرونکي تصدیق، او که اضافي ولرئ لغوه شوی تصدیق۔

منل شوی صادرونکی، د رول تصدیق او د لغوه کولو سرچینه د پروفایل ترڅنګ ثبت کړئ۔ همدا ثبت هغه څه دي چې بل انجینر ته پکار وي کله چې تیره میاشت کار کونکی وسیله ونښلول بند کړي، او دا هم ثبوت دی چې شرکت CA د عمومي هدف باور زباله دان په توګه نه، بلکې د مستند مننې حدودو دننه کارېږي۔