SoftEther ServerCertSet: vpncmd સાથે નવીકૃત શૃંખલા આયાત કરો

Certbot સફળ નવીકરણની જાણ કરે છે, ડિસ્ક પરની ફાઇલો નવી તારીખો ધરાવે છે, અને ગ્રાહકો હજી પણ જૂની ઓળખ સાથે મળે છે. SoftEther તેનું SSL સર્વર પ્રમાણપત્ર પોતાના સર્વર-સ્તરના રૂપરેખાંકનમાં રાખે છે, તેથી ડિસ્ક પરની નવી ફાઇલ ત્યાં સુધી કંઈ બદલતી નથી જ્યાં સુધી પર્ણ અને તેની કી આયાત ન થાય. નીચેનો ક્રમ એક હાથે કરેલી આયાત, દરેક નવીકરણ પછી ચાલતું આવરણ અને શ્રોતા ખરેખર શું રજૂ કરે છે તે વાંચતી તપાસને આવરી લે છે. દરેક પગલું એવા પુરાવા છોડે છે જે તમે આગલા નવીકરણ પછી સરખાવી શકો.

નવીકૃત ફાઇલ સર્વરની ઓળખ બદલતી નથી

ઇશ્યુ અને જમાવટ અલગ ઘટનાઓ છે જેમની નિષ્ફળતાની રીતો પણ અલગ છે. ACME ગ્રાહક ફાઇલોને વંશ ડિરેક્ટરીમાં લખે છે અને સફળતા નોંધે છે; SoftEther તેના રૂપરેખાંકનમાં છેલ્લે લોડ થયેલું પ્રમાણપત્ર વાપરવાનું ચાલુ રાખે છે. તેથી શૂન્ય એક્ઝિટ સ્થિતિ ફાઇલોનું વર્ણન કરે છે, સેવાનું નહીં, અને જ્યાં સુધી કોઈ જોતું નથી ત્યાં સુધી બંને અસહમત રહી શકે છે. આયાતને જમાવટનું પગલું અને નવીકરણને તેનું ઇનપુટ ગણો.

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

શ્રોતાને અનુરૂપ પડકાર પસંદ કરો

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

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

અહીં હો ત્યાં સુધી કલાકૃતિઓ વ્યવસ્થિત રાખો. પર્ણ અને મધ્યવર્તી પ્રમાણપત્રો અલગ ફાઇલો તરીકે અને એક સંયુક્ત શૃંખલા ફાઇલ તરીકે આવે છે, ખાનગી કી ફરી અલગ છે, અને આયાતને તેની મેળ ખાતી કી સાથેની શૃંખલા જોઈએ છે, એકલું જાહેર પ્રમાણપત્ર નહીં.

શૃંખલા સર્વર સ્તરે આયાત કરો

પ્રમાણપત્રને સ્પર્શ કરતાં પહેલાં સર્વર રૂપરેખાંકનનો બેકઅપ લો અને ખાતરી કરો કે તમે હજી સંચાલન ઇન્ટરફેસ સુધી પહોંચી શકો છો. Virtual Hub સંચાલક તરીકે નહીં, સર્વર સંચાલક તરીકે જોડાઓ, કારણ કે પ્રમાણપત્ર સર્વર ઑબ્જેક્ટનું છે. પછી શૃંખલા અને કી સંપૂર્ણ પથ દ્વારા લોડ કરો, એવી ફાઇલોમાંથી જે આદેશ ચલાવતું ખાતું વાંચી શકે. નોંધો કે પથ સંપૂર્ણ છે કારણ કે આદેશ તેમને vpncmd ચલાવનાર પ્રક્રિયાના કાર્ય નિર્દેશિકામાંથી ઉકેલે છે:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

જમાવટને હૂક કરો, નવીકરણને નહીં

હાથની આયાત કામ કરે પછી, એ જ પગલાં નાના આવરણમાં મૂકો અને સફળ નવીકરણ પછી ACME ગ્રાહકમાંથી તેને બોલાવો. Certbot હૂક માટે RENEWED_LINEAGE અને RENEWED_DOMAINS સેટ કરે છે, તેથી આવરણ અનેક પ્રમાણપત્રો સંભાળતી મશીન પર એક પ્રમાણપત્ર પર કાર્ય કરી શકે છે. હોસ્ટ પરના દરેક નવીકરણ પર પ્રતિક્રિયા આપવાને બદલે વંશ પ્રમાણે ગાળો. આવરણ એ જમાવટનો કોડ છે જે સર્વરના અધિકારોથી ચાલે છે, તેથી તે સ્થાનના અન્ય કોઈપણ સ્ક્રિપ્ટની જેમ તેની સમીક્ષા કરો.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

રજૂ કરેલી શૃંખલાની ફાઇલ સાથે સરખામણી કરો

ડિસ્ક નહીં, શ્રોતા વાંચો. ગ્રાહકો વાપરે છે તે સર્વર નામ સાથે ગ્રાહકતરફી પોર્ટ પર જોડાઓ, પછી ફિંગરપ્રિન્ટ અને પહોંચાડેલી શૃંખલાની હૂકે સ્થાપેલા વંશ સાથે સરખામણી કરો. બે આદેશ આને આવરી લે છે, અને પહેલો એ પણ દર્શાવે છે કે મધ્યવર્તી પ્રમાણપત્રો આવે છે કે નહીં:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

પછી નવું ગ્રાહક જોડાણ બનાવો, કારણ કે આયાત પહેલાં સ્થપાયેલા સત્રો અગાઉની ઓળખ સામે પ્રમાણિત થયા હતા અને નવા વિશે કંઈ સાબિત કરતા નથી. જો ગ્રાહકો જૂનું પર્ણ પિન કરે છે, તો જાહેર શૃંખલા માન્ય હોય તોપણ તેમને સંકલિત અપડેટની જરૂર છે, અને એ કાર્ય નવીકરણના એ જ રનબુકનું છે. સેવા સામેનો રિવર્સ પ્રોક્સી સારું પ્રમાણપત્ર રજૂ કરી શકે છે જ્યારે VPN શ્રોતા હજી જૂનું રાખે છે, અને તેથી તપાસે એ પોર્ટનું નામ આપવું પડે છે જ્યાં ગ્રાહકો ખરેખર પહોંચે છે. નવીકરણ તારીખની બાજુમાં ફિંગરપ્રિન્ટ નોંધો, જેથી આગલી સરખામણી સ્મૃતિનું કાર્ય નહીં, તપાસ બને.