Access Server માં વેબ પ્રમાણપત્ર ભૂલ: ખાલી CA બંડલનું સુધારણ

DNS યોગ્ય રીતે રિઝોલ્વ થતું હોવા છતાં લોડ ન થતું વેબ લોગિન પેજ સામાન્ય રીતે DNS સમસ્યા નથી. જો સેવા લોગ ખાલી પ્રમાણપત્ર-બંડલ પાથ અથવા વેબ પ્રમાણપત્ર અને ખાનગી કી માટે PEM પાર્સ નિષ્ફળતા નોંધે, તો HTTPS શ્રોતા પાસે કોઈ ઉપયોગી સામગ્રી નથી અને નામ રિઝોલ્યુશન કોઈ મદદ કરશે નહીં. સુધારણ ત્રણ કન્ફિગરેશન કીમાં છે અને કોઈપણ VPN ક્લાયન્ટ પ્રમાણપત્ર ફરી જારી કરવાની જરૂર નથી.

ત્રણ કી ખરેખર શું દર્શાવે છે

કસ્ટમ વેબ પ્રમાણપત્ર સેટ cs.cert, cs.priv_key અને cs.ca_bundle દ્વારા વર્ણવાય છે. દરેક ફાઇલનો પાથ સંગ્રહે છે અને વેબ સેવા ત્રણેયને સાથે વાપરે છે. ખોટી કી સાથેનું પ્રમાણપત્ર, અથવા ખરેખર લીફ પ્રમાણપત્ર હોય તેવી ચેઇન ફાઇલ, ખાલી મૂલ્યની જેમ નિષ્ફળ જાય છે: શ્રોતા બ્રાઉઝર સ્વીકારે તેવી ચેઇન બનાવી શકતો નથી.

આ કી Admin અને Client વેબ ઇન્ટરફેસની છે. તે VPN ક્લાયન્ટને પ્રમાણપત્ર આપતા PKI થી અલગ છે, તેથી બદલવા માટે ક્લાયન્ટ પ્રોફાઇલ, સર્વર કી કે પ્રમાણપત્ર સત્તાધિકારીને સ્પર્શ કરવાની જરૂર નથી. વેબ TLS નિષ્ફળતાને આખું PKI ફરી બનાવવાનું કારણ માનવું એ અહીં સૌથી મોંઘી ભૂલ છે.

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

હાલની ફાઇલ પણ કેમ પાર્સ થતી નથી

પાર્સર ફાઇલની અંદરના લેબલવાળા બ્લોક વાંચે છે, ફાઇલનું નામ નહીં. ખાનગી કી ધરાવતી .crt, એક પ્રમાણપત્રની અપેક્ષા હતી ત્યાં એક જ જોડાયેલ બ્લોક તરીકે લખાયેલી ચેઇન, અથવા અંતિમ લાઇન કપાયેલી ફાઇલ — બધી નકારાય છે. RFC 7468 તે વાંચી શકાય તેવા લેબલ વ્યાખ્યાયિત કરે છે કારણ કે તે જ વાચકને કહે છે કે આગળ કઈ પ્રકારની વસ્તુ છે.

ઑબ્જેક્ટ તપાસો, એક્સ્ટેન્શન નહીં. Linux હોસ્ટ પર openssl x509 -noout -subject -issuer -in server.pem અને openssl pkey -noout -check -in key.pem બે મહત્વના પ્રશ્નોના જવાબ આપે છે, અને બંનેનું મોડ્યુલસ કે જાહેર કી સરખાવવાથી સાબિત થાય કે તે એકસાથે છે. ખાનગી કીનું આઉટપુટ ટિકિટ અને ચેટ લોગથી દૂર રાખો; ચકાસણીને ફિંગરપ્રિન્ટ જોઈએ, કી નહીં.

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

જાણી જોઈને ફૉલબેક પર જાઓ

Access Server ના CLI માં ચકાસણી છે જે ત્રણ પાથને આર્ગ્યુમેન્ટ તરીકે લે છે અને સેટ ઉપયોગી છે કે નહીં જણાવે છે. નીચેના પાથ ઉદાહરણરૂપ છે; હોસ્ટ પરના સુરક્ષિત સ્થાનોથી બદલો:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

વપરાશકર્તા ખરેખર લખે છે તે નામ ચકાસો

જ્યારે કસ્ટમ સામગ્રી તૂટેલી હોય અને માન્ય બિલ્ટ-ઇન ફૉલબેક હજી હાજર હોય, ત્યારે દસ્તાવેજીકૃત પુનઃપ્રાપ્તિ એ ત્રણ કસ્ટમ ઓવરરાઇડ દૂર કરીને Access Server ને તે ફૉલબેક વાપરવા દેવાની છે. પહેલાં કન્સોલ પ્રવેશ અને વર્તમાન કન્ફિગરેશનનો બેકઅપ ગોઠવો, કારણ કે તમે પુનઃપ્રારંભ કરનાર સેવા એ જ છે જે વ્યવસ્થાપન ઇન્ટરફેસ પરોસે છે.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

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

સફળ સાઇન-ઇન પછી જ પુનઃપ્રાપ્તિ પૂર્ણ થાય છે

TCP શ્રોતા દેખાય કે તરત પુનઃપ્રાપ્તિ પૂર્ણ થતી નથી. DNS નામ, પ્રમાણપત્રની ઓળખ અને તે નામની ચેઇન ચકાસો, પછી Admin અને Client બંને વેબ ઇન્ટરફેસ લોડ કરીને સાઇન-ઇન પૂર્ણ કરો. પોર્ટ ચકાસણી એમાંથી કંઈ સાબિત કરતી નથી.

Access Server 3.1 અને પછીના દરેક SNI હોસ્ટનામ માટે અલગ વેબ પ્રમાણપત્ર પણ પરોસી શકે છે. જો તે ગોઠવેલું હોય, તો ડિફૉલ્ટ કી અને હોસ્ટનામ-વિશિષ્ટ એન્ટ્રી અલગ સેટ છે, અને IP સરનામાથી પરીક્ષણ કરવાથી વપરાશકર્તાઓને મળતા પ્રમાણપત્ર કરતાં અલગ પ્રમાણપત્ર સરળતાથી દેખાય છે. નિષ્ફળ ગયેલ નામનો સેટ સુધારીને ચકાસો, અને ઘટના બંધ કરતા પહેલાં સાઇન-ઇન પરીક્ષણ ફરીથી કરો.