કસ્ટમ CA બંડલ સાથે રીડાયરેક્ટ પછી SSL પ્રમાણપત્રની ભૂલો
ચકાસો કે સ્પષ્ટપણે પસંદ કરેલી CA ફાઇલમાં વાસ્તવિક વિનંતી માર્ગને જરૂરી તમામ વિશ્વાસ સામગ્રી છે, જેમાં રીડાયરેક્ટ થયેલા હોસ્ટનો સમાવેશ થાય છે.
કંપનીની CA ફાઇલ પ્રથમ URL સુધારે છે, પછી રીડાયરેક્ટ ચકાસણીમાં નિષ્ફળ જાય છે. ચકાસો કે કસ્ટમ CA વિકલ્પે ક્લાયન્ટના અગાઉના વિશ્વાસ ઇનપુટને બદલ્યો છે કે તેમાં ઉમેર્યો છે.
આ વર્તન TLS બેકએન્ડ અને વિકલ્પ પર આધાર રાખે છે. ફક્ત કોર્પોરેટ CA ધરાવતી ફાઇલ ક્લાયન્ટને તેને જરૂરી અન્ય સત્તાઓ વિના છોડી શકે છે.
- દરેક સાથીને અનુસરો. પ્રથમ હોસ્ટ કોર્પોરેટ ઇશ્યુઅર હેઠળ અટકાવી શકાય છે. પછીનો હોસ્ટ બાયપાસ, બીજો નિરીક્ષણ માર્ગ અથવા જાહેરમાં જારી કરેલી શૃંખલા વાપરી શકે છે.
- નિષ્ફળ ક્લાયન્ટના ઇનપુટ નોંધો. વિનંતી કરેલ હોસ્ટનામ, રીડાયરેક્ટ લક્ષ્ય, પ્રાપ્ત ઇશ્યુઅર, ચકાસણી પરિણામ અને પસંદ કરેલ વિશ્વાસ રૂપરેખાંકન રાખો. કાર્યરત બ્રાઉઝર બીજું રૂટ સ્ટોર વાપરી શકે છે.
- બેકએન્ડના પસંદગી નિયમો તપાસો. curl બિલ્ડ મૂળ ચકાસણી અથવા ફાઇલ-આધારિત રૂટ વાપરી શકે છે, અને સ્પષ્ટ CA વિકલ્પો તે પસંદગી બદલી શકે છે. તે એક્ઝિક્યુટેબલ માટેની રેસિપી Python પર્યાવરણ કે JVM ગોઠવતી નથી.
જાળવવામાં આવતું બંડલ અથવા સમર્થિત વિશ્વાસ-સ્ટોર ગોઠવણી વાપરો જેમાં એપ્લિકેશન વિશ્વાસ કરવાના જાહેર અને ખાનગી સત્તાધિકારીઓ હોય. CA ની ખાનગી કી ઉમેરશો નહીં અને માત્ર આગલી ભૂલ દૂર કરવા માટે દરેક નિષ્ફળ લીફ પ્રમાણપત્રને રૂટ સુધી બઢાવશો નહીં.
વિશ્વાસ સામગ્રી ડિપ્લોયમેન્ટના સમર્થિત અપડેટ માર્ગ દ્વારા પહોંચાડો. વેન્ડર CA પેકેજને જાતે બદલવું તેના આગલા અપડેટ દ્વારા રદ થઈ શકે છે; માલિક અને જાળવણી પ્રક્રિયા સ્પષ્ટ રાખો જેથી સંપૂર્ણ વિનંતી માર્ગ પર ચકાસણી ચાલુ રહે.