SoftEther ServerCertSet: i-import ang na-renew na chain gamit ang vpncmd
Hindi binabago ng na-renew na file ang pagkakakilanlan ng SoftEther server. I-import ang chain gamit ang ServerCertSet, i-hook ang hakbang ng deployment, at basahin ang listener.
Nag-uulat ang Certbot ng matagumpay na pag-renew, may mga bagong petsa ang mga file sa disk, at nakikita pa rin ng mga kliyente ang lumang pagkakakilanlan. Hinahawakan ng SoftEther ang SSL server certificate nito sa sarili nitong configuration sa antas ng server, kaya walang binabago ang bagong file sa disk hanggang ma-import ang leaf at ang key nito. Sinasaklaw ng sequence sa ibaba ang isang manu-manong import, isang wrapper na tumatakbo pagkatapos ng bawat pag-renew, at isang pagsusuri na nagbabasa kung ano ang aktuwal na ipinapakita ng listener. Bawat hakbang ay nag-iiwan ng ebidensiyang maihahambing mo pagkatapos ng susunod na pag-renew.
Hindi binabago ng na-renew na file ang pagkakakilanlan ng server
Ang pag-isyu at deployment ay magkahiwalay na pangyayari na may magkahiwalay na paraan ng pagkabigo. Nagsusulat ang ACME client ng mga file sa isang lineage directory at nagtatala ng tagumpay; patuloy na ginagamit ng SoftEther ang certificate na huling na-load sa configuration nito. Kaya inilalarawan ng zero exit status ang mga file, hindi ang serbisyo, at maaaring magkaiba ang dalawa hangga't walang tumitingin. Ituring ang import bilang hakbang ng deployment at ang pag-renew bilang input nito.
Ipinapaliwanag din ng pagkakaibang iyon ang nakalilitong kalahating pagkabigo: gumagana pa rin ang lumang certificate hanggang sa mag-expire ito, kaya sa simula ay walang mukhang sira. Kapag nag-expire ito, sabay-sabay na nabigo ang lahat ng kliyente, na mukhang pagkaantala at hindi hakbang ng deployment na nalampasan. Ang pagsuri sa ipinapakitang pagkakakilanlan pagkatapos ng bawat pag-renew ay ginagawang routine na obserbasyon ang sorpresang iyon.
Piliin ang challenge na umaangkop sa listener
Dapat pangalanan ng certificate ang host na bineberipika ng mga kliyente, kaya gamitin ang pampublikong DNS name sa halip na panloob na label o address. Kailangan ng HTTP-01 na masagot ang challenge sa port 80 sandali, na pansamantalang listener at hindi kailanman dahilan para ilipat ang sariling port ng SoftEther. Pinatutunayan ng DNS-01 ang kontrol sa pamamagitan ng record at hindi nangangailangan ng papasok na HTTP.
Ang pag-renew na walang nagbabantay ay nangangahulugan ng automatiko at integrasyong DNS na may mga kredensyal na limitado sa isang zone, hindi TXT record na kinakamay kada dalawang buwan. Binabago ng wildcard ang uri ng challenge, hindi ang pangangailangan sa automatisyong iyon. Pagpasyahan ito bago umiral ang unang certificate, dahil ang pagpapalit ng uri ng challenge mamaya ay nangangahulugan ng pagsasabay na paghawak sa configuration ng kliyente at firewall.
Panatilihing maayos ang mga artefact habang nandito ka. Dumarating ang leaf at mga intermediate bilang magkahiwalay na file at bilang isang pinagsamang chain file, hiwalay muli ang private key, at kailangan ng import ang chain kasama ang tugmang key nito, hindi pampublikong certificate lamang.
I-import ang chain sa antas ng server
Mag-backup ng configuration ng server at tiyakin na naaabot mo pa rin ang management interface bago hawakan ang certificate. Kumonekta bilang server administrator at hindi bilang Virtual Hub administrator, dahil pag-aari ng server object ang certificate. Pagkatapos i-load ang chain at key sa absolute path, mula sa mga file na kayang basahin ng account na nagpapatakbo ng command. Pansinin na absolute ang mga path dahil nireresolba ng command ang mga ito mula sa working directory ng prosesong nagpatakbo ng vpncmd:
ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pemBasahin ang output ng command sa halip na ipagpalagay ang tagumpay, at pagkatapos basahin muli ang chain sa halip na magtiwala sa file na ibinigay mo. Ang hangganan sa pagitan ng mga build na nag-iimport ng buong PEM bundle at ng mga build na kumukuha lamang ng unang certificate ay hindi nakadokumento sa isang lugar, kaya ang pagsusuri ang nagpapasya nito para sa build na nasa harap mo. Bilangin ang mga certificate na ipinapakita ng listener; ang leaf na walang intermediate ay pirma ng importer na gumamit lamang ng unang block.
Panatilihing nababasa lamang ng account na nagpapatakbo ng server ang na-import na key, at ilayo ang management password sa shell history. Sa unang import na ito, i-type ang password sa prompt sa halip na ipasa ito bilang argument ng command. Walang gastos ang dalawang gawi na ito at inaalis ang pinakakaraniwang paraan na nagbubunyag ang deployment ng certificate ng isang bagay na dapat nitong protektahan. Gawin ito bago ang unang import, hindi pagkatapos.
I-hook ang deployment, hindi ang pag-renew
Kapag gumana na ang manu-manong import, ilagay ang mga hakbang na iyon sa isang maliit na wrapper at tawagin ito mula sa ACME client pagkatapos ng matagumpay na pag-renew. Itinatakda ng Certbot ang RENEWED_LINEAGE at RENEWED_DOMAINS para sa hook, kaya makakagawa ng aksiyon ang wrapper sa isang certificate sa isang makina na namamahala ng marami. Salain ayon sa lineage sa halip na tumugon sa bawat pag-renew sa host. Ang wrapper ay deployment code na tumatakbo gamit ang mga pribilehiyo ng server, kaya suriin ito tulad ng anumang iba pang script sa ganoong posisyon.
certbot renew --deploy-hook /usr/local/sbin/softether-deploy.shAng hook na tumatakbo nang walang nagbabantay ay nangangailangan ng sariling protektadong imbakan ng kredensyal at signal ng pagkabigo na umaabot sa tao. Kung nagtagumpay ang pag-isyu at nabigo ang import, subukan muli ang import sa halip na humingi ng ibang certificate, dahil itinatago ng pangalawang kahilingan ang depekto ng deployment sa likod ng bagong file. Malinaw sa dokumentasyon ng pag-renew ng Certbot na ang run na walang ina-update ay normal na resulta, kaya ang hook ang nagtatangi sa dalawa.
Ihambing ang ipinakitang chain sa file
Basahin ang listener, hindi ang disk. Kumonekta sa port na nakaharap sa mga kliyente gamit ang server name na ginagamit ng mga kliyente, pagkatapos ihambing ang fingerprint at ang naihatid na chain sa lineage na inilagay ng hook. Dalawang command ang sumasaklaw nito, at ipinapakita rin ng una kung dumarating man ang mga intermediate:
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 -sha256Pagkatapos gumawa ng bagong koneksiyon ng kliyente, dahil ang mga sesiyong itinatag bago ang import ay na-authenticate laban sa dating pagkakakilanlan at wala silang pinapatunayan tungkol sa bago. Kung ipin-pin ng mga kliyente ang lumang leaf, kailangan nila ng koordinadong update kahit wasto ang pampublikong chain, at kabilang ang gawaing iyon sa parehong runbook ng pag-renew. Maaaring magpakita ng magandang certificate ang reverse proxy sa harap ng serbisyo habang hawak pa rin ng VPN listener ang luma, at iyon ang dahilan kung bakit dapat pangalanan ng pagsusuri ang port na aktuwal na naaabot ng mga kliyente. Itala ang fingerprint sa tabi ng petsa ng pag-renew, upang ang susunod na paghahambing ay isang pagsusuri at hindi gawaing memorya.