વેબસાઇટ ખોટું પ્રમાણપત્ર દર્શાવે છે? શ્રોતાને શોધો
એક સાઇટ અણધાર્યું પ્રમાણપત્ર રજૂ કરે છે અને સ્પષ્ટ ફાઇલ ફરીથી લખાય છે. પ્રથમ જવાબ આપનાર શ્રોતા અને વર્ચ્યુઅલ હોસ્ટને ઓળખો.
વેબ હોસ્ટ પર VPN સૉફ્ટવેર ઇન્સ્ટોલ કરવાથી સેવાઓ ફરીથી ગોઠવાઈ શકે છે, પરંતુ અણધાર્યું પ્રમાણપત્ર સાબિત કરતું નથી કે Apache ફાઇલો ફરીથી લખાઈ છે. કંઈકે તે પ્રમાણપત્ર તમારા બ્રાઉઝરને રજૂ કર્યું, અને પ્રથમ કાર્ય તેને નામ આપવાનું છે. જ્યાં સુધી શ્રોતા અને વર્ચ્યુઅલ હોસ્ટ ઓળખાય નહીં, ત્યાં સુધી દરેક સમારકામ ખોટા સ્તર પર લાગુ કરાયેલું અનુમાન છે. નીચેની સંપૂર્ણ તપાસ ફક્ત વાંચન માટે છે.
કેસ નક્કી કરતી હકીકતો એકત્રિત કરતી વખતે કંઈપણ ફરી શરૂ થતું નથી, અનઇન્સ્ટોલ થતું નથી કે ઉપર લખાતું નથી.
બ્રાઉઝરે ખરેખર મેળવેલું પ્રમાણપત્ર વાંચો
હોસ્ટનામ, દરેક કુટુંબ માટે ઉકેલાયેલું સરનામું, પોર્ટ અને બ્રાઉઝરે ફરિયાદ કરેલી પ્રમાણપત્રની વિગતો નોંધો. જે નામ A અને AAAA રેકોર્ડ બંનેમાં ઉકેલાય છે તે બે અલગ આગળના ભાગો સુધી પહોંચી શકે છે, અને તેમાંથી ફક્ત એક જ એ હોસ્ટ હોઈ શકે જ્યાં તમને શેલ ઍક્સેસ છે. પ્રોક્સી પાછળનું બ્રાઉઝર ફરીથી ત્રીજો રસ્તો લઈ શકે છે. ચેતવણી કોણે ઉત્પન્ન કરી તે અનુમાન કરવાથી તમારી પાસેનું એકમાત્ર અવલોકન બગડે છે.
પછી તે જ માર્ગ પરની મશીનમાંથી હેન્ડશેક ફરી ઉત્પન્ન કરો, સરનામું સ્પષ્ટ રીતે જણાવો અને ઇચ્છિત સર્વર નામ મોકલો જેથી જવાબ ડિફૉલ્ટ હોસ્ટને બદલે સાઇટ દર્શાવે.
openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName
વિષયના વૈકલ્પિક નામો અને ફિંગરપ્રિન્ટને તમે અપેક્ષા રાખો છો તે પ્રમાણપત્ર સાથે સરખાવો, પરિચિત ઇશ્યુ કરનાર સાથે નહીં. સર્વર નામ વિના નગ્ન સરનામા સાથે જોડાવાથી ડિફૉલ્ટ પ્રમાણપત્ર પસંદ થઈ શકે છે, જે પછી ખોટી ફાઇલ જેવું લાગે છે જ્યારે વાસ્તવમાં પ્રશ્ન ખોટો હોય છે.
તે પોર્ટ સાથે જોડાયેલી પ્રક્રિયા ઓળખો
જે હોસ્ટે કનેક્શન મેળવવાનું છે તેના પર શ્રોતાઓની સૂચિ બનાવો અને બાઇન્ડ સરનામું, સરનામા કુટુંબ અને પ્રક્રિયાનો માલિક નોંધો. લૂપબેક સરનામા સાથે જોડાયેલી સેવા બધા ઇન્ટરફેસ સાથે જોડાયેલી સેવા જેવી નથી, અને કન્ટેનર પ્રકાશન જાહેર શ્રોતાને સંપૂર્ણપણે બીજે સ્થાને મૂકી શકે છે.
sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'
જો TLS આગળની લોડ બેલેન્સર અથવા પ્રોક્સી દ્વારા સમાપ્ત થાય છે, તો અહીં થોભો અને તેના બદલે તે આગળનો ભાગ તપાસો. તેની પાછળનું Apache ઇન્સ્ટન્સ જાહેર બ્રાઉઝરને કદાચ ક્યારેય પ્રમાણપત્ર રજૂ ન કરે, તેથી તેની ગોઠવણી સંપાદિત કરવાથી બ્રાઉઝર જે જુએ છે તેમાં કંઈ બદલાતું નથી. સોકેટ દૃશ્ય અને બાહ્ય હેન્ડશેકે સમાન માર્ગ વર્ણવવો જોઈએ, અને આ સરખામણી તે જ સ્થાપિત કરે છે.
ફાઇલ પહેલાં વર્ચ્યુઅલ હોસ્ટ મેળવો
જ્યારે Apache સમાપક હોય, ત્યારે તેને પૂછો કે તે સરનામા અને નામ માટે કઈ વર્ચ્યુઅલ હોસ્ટ જીતે છે. નિયંત્રણ આદેશ અસરકારક લેઆઉટ છાપે છે, જેમાં દરેક સોકેટ સાથે મેળ ખાતો જૂથ, જાહેર કરેલા સર્વર નામો અને ડિફૉલ્ટ તરીકે ગણાતો હોસ્ટનો સમાવેશ થાય છે. તે જવાબ વિના પ્રમાણપત્ર ફાઇલ સંપાદિત કરવી એ છે કે કેવી રીતે ખોટી સાઇટ સાચી ફાઇલમાંથી પરોવાય છે.
sudo apachectl -S
Apache SSL પ્રશ્નોત્તરી સમજાવે છે કે સર્વર નામ સંકેત પ્રમાણપત્ર કેવી રીતે પસંદ કરે છે. HTTP Host હેડર હેન્ડશેક પછી આવે છે અને પહેલેથી રજૂ થયેલું પાછળથી બદલી શકતું નથી, તેથી ન મળતું અથવા ગેરહાજર નામ ડિફૉલ્ટ હોસ્ટ પર પાછું જાય છે.
ServerAlias માં ટાઇપિંગ ભૂલ ધરાવતું નામવાળું વર્ચ્યુઅલ હોસ્ટ બરાબર આ લક્ષણ ઉત્પન્ન કરે છે, અને પ્રથમ બધું પકડતું હોસ્ટ લોડ કરતી બીજી ગોઠવણી ફાઇલ પણ તેમ જ કરે છે. બંને તે લેઆઉટ સૂચિમાં દેખાય છે.
તમે દાવો કરો તે દરેક માર્ગ પર સુધારો ચકાસો
મંજૂર થયેલા ફેરફાર પછી, દરેક સરનામા કુટુંબ માટે હોસ્ટનામ-વિશિષ્ટ તપાસનું પુનરાવર્તન કરો અને બાયપાસ ફ્લેગને બદલે બ્રાઉઝરની સામાન્ય માન્યતા સાથે સમાપ્ત કરો. શેર કરેલી શ્રોતા ગોઠવણીઓને સ્પર્શતા પહેલાં અલગ વહીવટી માર્ગ જાળવી રાખો, કારણ કે ત્યાંની ભૂલ તે ઍક્સેસ દૂર કરે છે જેનો ઉપયોગ તમે તેને પૂર્વવત્ કરવા માટે કરો છો. પછી નોંધો કે કયા શ્રોતાએ જવાબ આપ્યો, કઈ વર્ચ્યુઅલ હોસ્ટ મળી અને પહેલાં તથા પછી કયું પ્રમાણપત્ર પરોવાયું.
પેકેજ દૂર કરવાથી લેઆઉટ બદલાઈ શકે છે અને મૂળ અસંગતિ સમજૂતી વિના રહી શકે છે, તેથી જ તે રેકોર્ડ સમારકામ કરતાં વધુ ટકે છે.
તમે ઇચ્છો છો તે ઇચ્છિત પ્રવેશ બિંદુ પર ઇચ્છિત સાઇટ છે. અસંબંધિત સેવા અદૃશ્ય થયા પછીનું અલગ પ્રમાણપત્ર તે પરિણામ નથી, બ્રાઉઝર ફરિયાદ કરવાનું બંધ કરે તો પણ.