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 સામાન્ય હેતુના વિશ્વાસ-ડમ્પ તરીકે નહીં પરંતુ દસ્તાવેજીકૃત સ્વીકૃતિ-સીમાની અંદર વપરાય છે.

સંબંધિત લેખો