ક્રોસ-સાઇન્ડ CA: કી મેળ ખાય છે, AKI બાઇન્ડિંગ નહીં

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

આ પાંચ તપાસ ક્રમમાં કરો: દરેક અલગ નિષ્ફળતાને બાકાત કરે છે.

તપાસ 1: ટેમ્પલેટને અડકતા પહેલાં બંને ચેઇન દોરો

માર્ગો લખી લો. જૂની વસ્તી જૂના રૂટ A પર ભરોસો કરે છે, જેણે CA B બહાર પાડ્યું, જેણે સર્વરની લીફ બહાર પાડી. નવી વસ્તી સીધા સ્વ-સાઇન્ડ CA B પર ભરોસો કરે છે. બંને B પ્રમાણપત્રો સમાન કી અને સબ્જેક્ટ ધરાવે છે, અને તે જ કારણે સબ્જેક્ટ લાઇન વાંચનાર વ્યક્તિ એક CA જુએ છે જ્યાં ક્લાયન્ટ બે જુએ છે.

ક્રોસ-સાઇન્ડ નકલ પણ ખરેખર CA પ્રમાણપત્ર હોવું જોઈએ, જેમાં basic constraints અને key usage સહી કરવાની મંજૂરી આપે.

તપાસ 2: ફક્ત કી નહીં, AKI ફીલ્ડની સરખામણી કરો

લીફના ઇશ્યુઅર નામે B ના સબ્જેક્ટ સાથે મેળ ખાવો જોઈએ, અને તે ભાગ સામાન્ય રીતે ચાલે છે. બે નકલો જ્યાં અલગ પડે છે તે Authority Key Identifier છે, કારણ કે તે કી ઓળખકર્તા, ઇશ્યુઅર પ્રમાણપત્ર અને સીરિયલ નંબર ધરાવી શકે છે. કી ઓળખકર્તા બંને નકલો સાથે મેળ ખાય છે, કારણ કે કી સમાન છે. ઇશ્યુઅર અને સીરિયલ ફીલ્ડ ચોક્કસપણે એક સાથે મેળ ખાય છે, અને તેથી સ્વ-સાઇન્ડ નકલ સામે બનતી ચેઇન ક્રોસ-સાઇન્ડ નકલ સામે નિષ્ફળ જઈ શકે છે.

અનુમાન કરવાને બદલે લીફની તપાસ કરો: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

પછી બંને ઉમેદવારોને openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" સાથે સરખાવો, અને એ જ આદેશ સ્વ-સાઇન્ડ નકલ સામે ચલાવો.

જો લીફ ઇશ્યુઅર અને સીરિયલ ધરાવે છે, તો ફક્ત તે જ પ્રમાણપત્ર ચેઇન પૂર્ણ કરે છે જે તે મૂલ્યો વર્ણવે છે, ક્લાયન્ટે કોઈ પણ નકલ લોડ કરી હોય.

તપાસ 3: ઇશ્યુઇંગ પોલિસી બદલો, ક્યારેય સાઇન્ડ બાઇટ નહીં

એક્સ્ટેન્શન સહીની અંદર રહે છે. હાલની લીફ પર એક ઉમેરવું, દૂર કરવું કે સંપાદિત કરવું તે સમારકામ નથી, તે અલગ પ્રમાણપત્ર છે, અને તેને ફરી ઇશ્યુ કરવું પડે. ફેરફાર ઇશ્યુઇંગ પોલિસીમાં આવે છે: authorityKeyIdentifier = keyid,issuer:always નવી લીફને પ્રમાણપત્ર-વિશિષ્ટ જોડાણ ધરાવવા દે છે, જ્યારે એકલું keyid વધુ ઢીલું સ્વરૂપ રાખે છે જે જાણી જોઈને ક્રોસ-સાઇનિંગ સંક્રમણને અનુકૂળ છે. આગલી બેચ સાઇન થાય તે પહેલાં નક્કી કરો કે તમારી PKI કઈ ઇચ્છે છે.

શેર કરેલ ટેમ્પલેટમાં ફેરફાર તમારી સામેના સર્વર પૂરતું નહીં, દરેક ભાવિ પ્રમાણપત્રને પણ બદલે છે.

તપાસ 4: દરેક ટ્રસ્ટ વસ્તીને અલગથી ચકાસો

જૂનો માર્ગ અને નવો માર્ગ અલગ રન તરીકે પરીક્ષણ કરો. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ક્રોસ-સાઇન્ડ માર્ગ કસે છે, અને નવા રૂટ સાથે અને untrusted ફાઇલ વગરનો એ જ આદેશ સ્વ-સાઇન્ડ માર્ગ કસે છે. બંને રૂટ એક બંડલમાં ભેળવવાથી કઈ ચેઇન પસંદ થઈ તે છુપાઈ જાય છે. તે પછી વાસ્તવિક ક્લાયન્ટ સાથે પુનરાવર્તન કરો, કારણ કે VPN બેકએન્ડ ચેઇનને પ્રાધાન્ય આપી શકે છે અથવા પ્રમાણપત્ર પિન કરી શકે છે એવી રીતે જે openssl કરતું નથી.

ઇન્ટરમીડિયેટ પ્રમાણપત્ર ક્લાયન્ટ ખરેખર વાંચે છે તે સેવા રૂપરેખાંકન દ્વારા પહોંચાડો, વિકિ પૃષ્ઠ દ્વારા નહીં.

તપાસ 5: જૂનો માર્ગ નિવૃત્તિ ઘડિયાળ પર રાખો

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

જો દરેક ક્લાયન્ટ લીફ ખસે તે પહેલાં નવો રૂટ સ્વીકારી શકે, તો સાદું ડ્યુઅલ-ટ્રસ્ટ રોલઆઉટ ક્રોસ-સાઇનિંગ કરતાં સરળ છે, અને નિવૃત્ત કરવા માટે એક વસ્તુ ઓછી રાખે છે.