IKEv2 માં બે સહીઓ છે: પ્રમાણપત્ર અને IKE_AUTH

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

પ્રમાણપત્રમાંથી ઇશ્યુઅરની સહી વાંચો

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

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

બંને લેબલ અલગ નોંધ તરીકે લખો. પ્રથમ CAનું વર્ણન કરે છે, બીજું સબ્જેક્ટની કીનું, અને બંનેમાંથી કોઈ ઓનલાઇન સહીની આગાહી કરતું નથી.

IKE વિનિમયમાંથી ઓનલાઇન સહી વાંચો

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

ipsec statusall | grep -i "auth\|proposal"

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

RFC 7427 શું બદલે છે અને શું નહીં

મૂળ પદ્ધતિઓ RFC 7296 માં દરેક અલ્ગોરિધમ સંયોજન મુજબ ક્રમાંકિત છે. પછીનું RFC 7427 સહી એક્સટેન્શન સહી-હેશ સમર્થનના સંકેત સાથે સામાન્ય Digital Signature પદ્ધતિ ઉમેરે છે, તેથી નવા હેશને પોતાનો પદ્ધતિ-ક્રમાંક જોઈતો નથી. તે વાટાઘાટનો વિષય છે, ધારણાનો નહીં: પીઅરને એક્સટેન્શન એટલા માટે મળતું નથી કે તેની લાઇબ્રેરી એ જ પ્રમાણપત્રો પાર્સ કરી શકે, અને જે પીઅર ફક્ત મૂળ પદ્ધતિઓ અમલમાં મૂકે છે તે ગેટવેને તેમાંથી એક રાખવા મજબૂર કરે છે. તે સુસંગતતાના ખર્ચ સાથેની નીતિ-અદલાબદલી છે, ખામી નહીં.

સમર્થન દરેક દિશા અને દરેક જોડાણ મુજબ છે, તેથી કુટુંબ-સ્તરના દાવા પર ભરોસો કરવાને બદલે તમારી સામેનું બિલ્ડ ચકાસો. ત્રણ વર્ષ પહેલાં લખાયેલું ક્ષમતા-મેટ્રિક્સ ત્રણ વર્ષ જૂનાં બિલ્ડ વર્ણવે છે.

યાદીમાં ચાર પંક્તિ મૂકો

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

દરેક પંક્તિ પોતાનું સુસંગતતા-પરિણામ ધરાવે છે. ESP સાઇફર બદલવાથી ઇશ્યુઅરની સહી પસંદ થતી નથી, અને CA ચકાસણી ઢીલી કરવાથી એવી ઓનલાઇન પદ્ધતિ ઉમેરાતી નથી જે પીઅરોએ ક્યારેય વાટાઘાટ ન કરી હોય. જ્યારે ટિકિટ સહી-અસંગતિનો દાવો કરે છે, ત્યારે ખરેખર ખોટી પંક્તિ લગભગ ક્યારેય પહેલી હોતી નથી.

PKI નબળી કર્યા વિના જૂનો કેસ નક્કી કરો

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

પછી બંને વાંચન ઉપરથી ફરી ચલાવો, કારણ કે એક પંક્તિમાં ફેરફાર બીજીમાં વાટાઘાટને ખસેડી શકે છે. આખી યાદી બે આદેશ અને એક કોષ્ટક છે, અને પીઅર રાઉટર, લેપટોપ કે ઉપકરણ હોય તો પણ કામ એ જ છે.