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

અવિભાજ્ય સંખ્યાઓ શોધતાં પહેલાં ખાતરી કરો કે કી RSA છે

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

આ ત્રણ ફક્ત-વાંચન આદેશો પ્રશ્નનો જવાબ આપે છે અને સાધનની આવૃત્તિ નોંધે છે.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

આવૃત્તિનું મહત્ત્વ છે કારણ કે વિકલ્પોનાં નામ મુખ્ય આવૃત્તિઓ વચ્ચે ખસ્યાં છે. પ્રમાણપત્રના આઉટપુટમાં જાહેર કી અલ્ગોરિધમની લાઇન અને કીનું માપ શોધો; કીના આઉટપુટમાં RSA કી મોડ્યુલસ અને જાહેર ઘાતાંક છાપે છે. લંબગોળ વણાંકની કી તેના બદલે નામવાળો વણાંક છાપે છે, અને કોઈ પણ શોધ તેમાંથી n કે q આપશે નહીં.

base64 ને બદલે રચના વાંચો

PEM એ હેડર લાઇનોમાં વીંટાયેલું base64 છે, અને તેને ડિકોડ કરવાથી DER મળે છે, જે વિશાળ પૂર્ણાંક નહીં પણ ક્રમિક રચના છે. RSA ખાનગી કીઓ બે સામાન્ય કન્ટેનરમાં મુસાફરી કરે છે, PKCS#1 અને PKCS#8, અને બંને એ જ સંખ્યાઓના સમૂહમાં ઉકેલાય છે.

બે અવિભાજ્ય સંખ્યાના કિસ્સામાં ખાનગી રચનામાં નવ ક્ષેત્રો હોય છે: એક આવૃત્તિ, મોડ્યુલસ n, જાહેર ઘાતાંક e, ખાનગી ઘાતાંક d, અવિભાજ્ય સંખ્યાઓ p અને q, બે CRT ઘાતાંક અને એક CRT ગુણાંક. RFC 8017 વિભાગ A.1 એ ઘટકો અને ASN.1 ગોઠવણ વ્યાખ્યાયિત કરે છે, અને બે કરતાં વધુ અવિભાજ્ય સંખ્યાઓ પણ માન્ય ગણે છે, તેથી સામાન્ય પાર્સર વધારાની અવિભાજ્ય નોંધો છાપી શકે છે. ક્રમ પર ધ્યાન આપો, કારણ કે તે એક સામાન્ય ભૂલ સમજાવે છે: જાહેર અડધો ભાગ ખાનગી ફાઇલની અંદર સંગ્રહાય છે, તેથી જાહેર ક્ષેત્રની હાજરી એ ફાઇલને શેર કરવા સુરક્ષિત બનાવતી નથી. તેના પછીનું બધું એ સામગ્રી છે જે હોસ્ટ પર જ રહેવી જોઈએ.

એન્કોડિંગ એવું સ્તર ઉમેરે છે જે સામગ્રી સાથે ભેળવી દેવું સહેલું છે. openssl asn1parse રચનાને વૃક્ષ તરીકે દોરે છે જેથી ક્ષેત્રોનો ક્રમ દેખાય, અને તે કંઈ ડિક્રિપ્ટ કરતું નથી કે કી વપરાયોગ્ય છે કે નહીં તે પણ કહેતું નથી.

કી છાપ્યા વિના પ્રમાણપત્રને કી સાથે જોડો

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

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

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

પડોશી ફાઇલો શું નથી તે જાણો

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

FileAnswersDoes not prove
vpn-client.keyPossession of the private keyThat the identity is enrolled
vpn-client.crtA signed binding of public key to identityThat the client holds the matching key
vpn-client.csrThe requested binding and public keyThat access was granted
dh2048.pemGroup parameters for key exchangeAny RSA component
crl.pemRevocation status for certificatesAnything about a private key

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

તેથી દરેક ઇન્વેન્ટરી લાઇને ચાર વસ્તુ નોંધવી જોઈએ: ઑબ્જેક્ટ પ્રકાર, માલિક, હેતુ અને ખાનગી સામગ્રી સમાવેલી છે કે નહીં. છેલ્લો સ્તંભ નક્કી કરે છે કે ફાઇલ ક્યાં કૉપી કરી શકાય, અને લોકો એ જ છોડી દે છે.

જોડી નોંધો, પછી હેન્ડશેક ચકાસો

કંઈ બદલતાં પહેલાં ચકાસણીનું આઉટપુટ તારીખ અને OpenSSL આવૃત્તિ સાથે સાચવો. પછીનું પરિભ્રમણ યાદશક્તિને બદલે પુરાવા સાથે સરખાવી શકાય.

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

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

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

સંબંધિત લેખો