SSTP પ્રમાણપત્ર મેળ ખાતું નથી: તમારા સર્વરે જે નામ રજૂ કરવું પડશે
ક્લાયન્ટ પ્રોફાઇલના હોસ્ટનામની પ્રમાણપત્ર સાથે સરખામણી કરે છે, પછી ચેઇન અને હેતુ ચકાસે છે. પ્રોફાઇલ કે પ્રમાણપત્ર સુધારો, માન્યતા ક્યારેય નહીં.
SSTP ક્લાયન્ટ ફક્ત TLS માન્યતા સફળ થયા પછી જ સર્વર સ્વીકારે છે, અને એ ચકાસણી એક નામ, એક ચેઇન અને એક હેતુ સરખાવે છે. નામ કનેક્શન પ્રોફાઇલમાંથી આવે છે, તમે સંજોગવશાત્ પિંગ કરી શકો તે સરનામાંમાંથી નહીં. ત્રણમાંથી એક પણ ન મળે તો ક્લાયન્ટ પ્રમાણપત્ર સમસ્યા જણાવે છે અને ક્યારેય લોગિન પ્રોમ્પ્ટ સુધી પહોંચતું નથી.
પ્રોફાઇલનું નામ નક્કી કરે છે કે શું ચકાસવું
SSTP TCP 443 પર TLS ચલાવે છે, તેથી ક્લાયન્ટ અન્ય કોઈપણ TLS ક્લાયન્ટની જેમ વર્તે છે: પ્રોફાઇલમાંથી હોસ્ટનામ લે છે, એ નામ માગે છે અને તેની સાથે પ્રમાણપત્ર સરખાવે છે. પ્રોફાઇલમાં IP સરનામું લખો તો સરખામણી IP સરનામાંની સરખામણી બની જાય છે, જે મોટાભાગના સર્વર પ્રમાણપત્રો પૂરી કરતા નથી.
તેથી બ્રાઉઝર પરીક્ષણ સફળ થઈ શકે છે જ્યારે VPN નિષ્ફળ જાય છે, કારણ કે બ્રાઉઝરે પ્રોફાઇલ કરતાં અલગ નામ વાપર્યું છે. એ જ ફાટ ત્યારે દેખાય છે જ્યારે split-horizon DNS VPN હોસ્ટનામને આંતરિક સરનામામાં ઉકેલે છે જ્યારે બ્રાઉઝર જાહેર સરનામે પહોંચ્યું હોય છે. પહેલાં પ્રોફાઇલને દસ્તાવેજીકૃત હોસ્ટનામ સાથે લાગુ કરો, પછી પ્રમાણપત્રો સરખાવો. એ પહેલાં તમે બદલો તે બીજું કંઈપણ અનુમાન છે.
સર્વર પ્રમાણપત્રમાં શું હોવું જોઈએ
આધુનિક ક્લાયન્ટ subject alternative name વિસ્તરણ સાથે સરખાવે છે, તેથી હોસ્ટનામ ત્યાં DNS પ્રવેશ તરીકે હોવું જોઈએ. ફક્ત common name આજના માન્યતા સ્ટેક માટે પૂરતું નથી, અને વાઇલ્ડકાર્ડ એક લેબલ આવરે છે, તમે બનાવો તે કોઈપણ સબડોમેન નહીં. ત્રણ પ્રમાણપત્રો સીમા દર્શાવે છે: સાચું નામ ખોટા હેતુ સાથે ઓળખની માન્યતા કરે છે અને પછી હેતુ ચકાસણીમાં નિષ્ફળ જાય છે, સાચાં નામ અને હેતુ સાથે ગુમ થયેલું મધ્યવર્તી પ્રમાણપત્ર ચેઇનમાં નિષ્ફળ જાય છે, અને જે નામ ફક્ત common nameમાં છે તે એ બેમાંથી કોઈ પણ મહત્વનું થાય તે પહેલાં નિષ્ફળ જાય છે.
પ્રમાણપત્રને સર્વર પ્રમાણીકરણનો હેતુ પણ જોઈએ: માઇક્રોસોફ્ટની SSTP સ્પેસિફિકેશનમાં માં નામ આપેલું extended key usage મૂલ્ય, એટલે કે ઑબ્જેક્ટ ઓળખકર્તા 1.3.6.1.5.5.7.3.1 સાથેનું serverAuth. key usage અને માન્ય ચેઇન સમૂહ પૂર્ણ કરે છે. સર્વર પર રહેલું, સાચા નામ માટે ઇશ્યૂ થયેલું પણ ફક્ત ક્લાયન્ટ પ્રમાણીકરણ માટેનું પ્રમાણપત્ર પણ નિષ્ફળ જાય છે.
લોગિન વિગતો પહેલાં ચેઇન અને ઘડિયાળ ચકાસો
સમય અને વિશ્વાસની નિષ્ફળતાઓ નામ ન મળવા જેવું જ દૃશ્ય પરિણામ આપે છે, અને બંને પાસવર્ડ સમસ્યા કરતાં સસ્તે નિદાન થાય છે. સર્વરની ઘડિયાળ અને ક્લાયન્ટની ઘડિયાળ ચકાસો, પછી ક્લાયન્ટ જેમ જુએ તેમ ચેઇન વાંચો:
# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /statusપ્રથમ કમાન્ડ નામ, માન્યતા વિન્ડો અને ક્લાયન્ટ સરખાવશે તે વૈકલ્પિક નામો છાપે છે. બીજું રજૂ કરેલી ચેઇન સાથે ચકાસણીની ભૂલો જણાવે છે, અને ત્યાં જ ગુમ થયેલું મધ્યવર્તી પ્રમાણપત્ર દેખાય છે. Windows પર સમય સેવાની પૂછપરછ જણાવે છે કે ઘડિયાળ સુધારાઈ રહી છે કે ફક્ત ખસી ગઈ છે.
આંતરિક CA એક વધુ શરત ઉમેરે છે: ક્લાયન્ટને તે CA પર વિશ્વાસ હોવો જોઈએ. સંસ્થાકીય રૂટ તેના મંજૂર વિતરણ કેનાલ દ્વારા સ્થાપિત કરો, રિપ્લેસમેન્ટ પ્રમાણપત્ર આપતા પૃષ્ઠ પરથી નહીં, કારણ કે એ નિર્ણય જ આખું વિશ્વાસ મોડેલ નાના પાયે છે.
સર્વર માન્યતા અને વપરાશકર્તા પ્રમાણીકરણ જુદી જુદી નિષ્ફળતાવાળા ક્રમિક તબક્કા છે. પ્રમાણપત્ર ભૂલનો અર્થ છે કે ક્લાયન્ટે સર્વર પર ક્યારેય વિશ્વાસ કર્યો નહીં, જ્યારે નકારાયેલો પાસવર્ડ એટલે કે તેણે સર્વર પર વિશ્વાસ કર્યો અને વિગતો ખોટી હતી. પાસવર્ડ પ્રોમ્પ્ટ સુધી પહોંચવા પ્રમાણપત્ર માન્યતા બંધ કરવી એ સુધારવાને બદલે ગેરંટી દૂર કરે છે. બાકીનો રસ્તો કામ કરે છે તે સાબિત કરવા, ચેઇન પર પહેલેથી વિશ્વાસ ધરાવતા ક્લાયન્ટથી એ જ હોસ્ટનામ અને પોર્ટ ચકાસો, અને તૈનાત પ્રોફાઇલને અડ્યા વિના રહેવા દો.
નામ કે પ્રમાણપત્ર સુધારો અને ફરી પરીક્ષણ કરો
ત્રણ શરતો સુધારણા નક્કી કરે છે. પ્રોફાઇલનું નામ ખોટું હોય તો પ્રોફાઇલ સુધારો અથવા પ્રમાણપત્રમાં ગુમ થયેલું નામ ઉમેરો. ચેઇન અધૂરી હોય તો સર્વર પર મધ્યવર્તી પ્રમાણપત્ર સ્થાપિત કરો. હેતુ ખોટો હોય તો આસપાસ પેચ કરવાને બદલે ફરી ઇશ્યૂ કરો.
ફેરફાર પછી સમર્થિત ક્લાયન્ટ સાથે ફરી જોડાઓ અને ખાતરી કરો કે લોગિન પ્રોમ્પ્ટ દેખાય છે, પછી ટનલ ઉપર આવે છે. ટિકિટમાં વપરાયેલું હોસ્ટનામ, ઇશ્યુઅર અને સમાપ્તિ તારીખ નોંધો. એ રેકોર્ડ જ આગલી નવીકરણને બીજા વિક્ષેપને બદલે સુનિશ્ચિત કાર્ય બનાવે છે, અને આગલી વ્યક્તિને દર્શાવે છે કે ત્રણ શરતોમાંથી કઈ ખરેખર તૂટી હતી.