ઓપરેટર એક સરનામું અને વપરાશકર્તા નામ મોકલે છે, અને ક્લાયન્ટ CA ફાઇલ, સર્ટિફિકેટ અને કી માંગે છે. આ ત્રણને સ્થાનિક રીતે બનાવવું સ્વાભાવિક આગળનું પગલું લાગે છે. એવું સર્ટિફિકેટ બને છે જેમાં ફક્ત તમારું જ મશીન માને છે. સર્વરનો ભરોસો એવી CAમાં જડાયેલો છે જે તમે નિયંત્રિત કરતા નથી, તેથી હેન્ડશેક શરૂ થતાં પહેલાં જ પૂરો થાય છે.

ભરોસો સર્વર પર રહે છે, તમારી પ્રોફાઇલમાં નહીં

સર્ટિફિકેટ પ્રમાણીકરણ એક તુલના છે. ક્લાયન્ટ સર્ટિફિકેટ રજૂ કરે છે; ગેટવે તપાસે છે કે તે તેની રૂપરેખાંકનની કોઈ CA દ્વારા સહી થયું છે કે નહીં.

તમારી પ્રોફાઇલ તે CA ફાઇલનું નામ આપે છે જે ક્લાયન્ટે સર્વરને ચકાસવા માટે વાપરવી જોઈએ. તે એવી CAનું નામ આપી શકતી નથી જે સર્વરે તમને ચકાસવા માટે વાપરવી જોઈએ. રૂપરેખાંકનનો એ અડધો ભાગ તમારો નથી.

તમે જાતે બનાવેલું સર્ટિફિકેટ ટેકનિકલી સંપૂર્ણ હોવા છતાં આ તુલનામાં નિષ્ફળ જાય છે. તેની પાસે માન્ય સહી, વિષય અને તારીખો છે, પરંતુ જારીકર્તા એવી CA છે જેનું નામ ગેટવેએ ક્યારેય સાંભળ્યું નથી. ભૂલ હેન્ડશેક દરમિયાન દેખાય છે, સર્વર પહેલેથી સર્ટિફિકેટ માંગી લીધા પછી. ક્લાયન્ટ પ્રોફાઇલમાં કંઈપણ જવાબ બદલી શકતું નથી.

શા માટે સ્વ-સહી કરેલું સર્ટિફિકેટ તેનું સ્થાન લઈ શકતું નથી

સ્વ-સહી કરેલું સર્ટિફિકેટ તેની પોતાની કી દ્વારા સહી થાય છે. સહી એ જ ફાઇલ સામે ચકાસાય છે, જે તેને સ્વ-સુસંગત અને બીજાના ગેટવે માટે ઓળખપત્ર તરીકે નકામું બનાવે છે.

ગેટવે એ પૂછતું નથી કે સર્ટિફિકેટ આંતરિક રીતે સુસંગત છે કે નહીં. તે પૂછે છે કે વિશ્વસનીય જારીકર્તાએ તેને સહી કરી છે કે નહીં.

એટલે જ ભૂલ સંદેશાઓ ગૂંચવણભર્યા છે. ક્લાયન્ટ એવી ચકાસણી નિષ્ફળતા જાણ કરી શકે છે જે સર્વરની સમસ્યા જેવી લાગે, જ્યારે સર્વર અજાણ્યા જારીકર્તાની નોંધ કરે છે. બંને એ જ વિસંગતિને વિરુદ્ધ છેડેથી વર્ણવે છે.

CSR માર્ગ તમારી ખાનગી કી રાખે છે

તમે હજી પણ મોટાભાગનું કામ સ્થાનિક રીતે કરી શકો છો. કી જોડી બનાવો, જાહેર અડધા ભાગની આસપાસ સર્ટિફિકેટ સહી કરવાની વિનંતી બનાવો અને તે વિનંતી ઓપરેટરને મોકલો. ફક્ત વિનંતી જ તમારા મશીનમાંથી નીકળે છે. ખાનગી અડધો ભાગ તમે જ્યાં બનાવ્યો ત્યાં જ રહે છે.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

ઓપરેટર પોતાની CA સાથે વિનંતી પર સહી કરે છે અને સર્ટિફિકેટ પાછું મોકલે છે. તમારી ખાનગી કી ક્યારેય મુસાફરી કરી નથી, અને પરિણામ ગેટવે જે એન્કર પર ભરોસો કરે છે તેની સાથે સાંકળાય છે.

મેનેજ્ડ સેવાઓ ઘણી વાર CSR છોડી દે છે અને આખું બંડલ જારી કરે છે. જ્યારે એ જ પ્રદાતા પહેલેથી ટનલ સમાપ્ત કરે છે અને CA ધરાવે છે ત્યારે તે વાજબી બદલો છે. કી રાખવાથી તેની સંભાળ સુધરતી નથી, કારણ કે પ્રદાતા કોઈપણ સમયે નવી બનાવી શકે છે.

બંડલ આયાત થાય છે, ઇન્સ્ટોલ થતાં નથી

સુરક્ષા જેવા નામ ધરાવતાં વેન્ડર બંડલ ઘણી વાર OpenVPN પ્રોફાઇલ હોય છે. તેમાં રૂપરેખાંકન અને ક્યારેક સર્ટિફિકેટ હોય છે, અને તે કંઈ ઇન્સ્ટોલ કરતાં નથી. ફાઇલને એવા ક્લાયન્ટમાં આયાત કરો જે પ્રોટોકોલ બોલે છે, અને જોડાણ રૂપરેખાંકિત થઈ જાય છે.

હેન્ડલિંગ નિયમ સામગ્રીમાંથી આવે છે. જો પ્રોફાઇલમાં ખાનગી કી સમાયેલી હોય, તો તે ઓળખપત્ર છે અને પાસવર્ડ જેવી જ કાળજી લાયક છે: ઈમેલ નહીં, રિપોઝિટરી નહીં, વહેંચાયેલ ડાઉનલોડ ફોલ્ડર નહીં. જ્યારે ઓપરેટર ca.crt, client.crt અને client.key અલગ રીતે આપે, ત્યારે તેમને પ્રતિબંધિત પરવાનગીઓ સાથે સાથે રાખો અને પ્રોફાઇલને તેમની તરફ નિર્દેશ કરો.

ઓપરેટરે જે ચકાસણીઓ છોડી હોઈ શકે તે ઉમેરો

રાઉટર દ્વારા બનેલી પ્રોફાઇલમાં ક્યારેક પીઅર ચકાસણી નથી હોતી. remote-cert-tls server માંગે છે કે પીઅર સર્ટિફિકેટમાં સર્વર પ્રમાણીકરણનો હેતુ હોય, જેથી ક્લાયન્ટ સર્ટિફિકેટને સર્વર તરીકે ફરી ચલાવી ન શકાય. તે એક લીટી સ્પષ્ટ વાજબીપણા સાથેનો નાનો ફેરફાર છે.

verify-x509-name ત્યારે આગળ જાય છે જ્યારે ઓપરેટર અપેક્ષિત વિષય અથવા SANનું નામ આપી શકે. બંને પ્રોફાઇલમાં નાના ઉમેરા છે, અને બંને વાજબી છે. આયાત કરતાં પહેલાં તમે જે મેળવ્યું છે તેની તપાસ કરો.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

ચકાસણી સેટિંગ્સ તૂટેલી સાંકળનું સમારકામ નથી. જો જારીકર્તા ખોટો હોય, તો જવાબ સાચી CAનું સર્ટિફિકેટ છે, ચકાસણી બંધ કરતો ધ્વજ નહીં. ચકાસણી બંધ કરવાથી પ્રમાણીકરણ નિષ્ફળતા અદૃશ્ય નિષ્ફળતામાં ફેરવાય છે.

એક બંડલ માંગો: સત્તાધિકારીનું સર્ટિફિકેટ PEM તરીકે, તે સત્તાધિકારી દ્વારા સહી કરેલું ક્લાયન્ટ સર્ટિફિકેટ, તમે બનાવેલી કી અથવા વિશ્વાસપાત્ર ચેનલ દ્વારા આવેલી કી, અને સર્ટિફિકેટે રજૂ કરવાનું સચોટ સર્વર નામ. તે જ સંદેશમાં સમાપ્તિ તારીખ નોંધો, કારણ કે સમાપ્ત થયેલું સર્ટિફિકેટ મહિનાઓ પછી નેટવર્ક ખામી જેવું લાગે છે.

સંબંધિત લેખો