SoftEther ServerCertSet: importi la renovigitan ĉenon per vpncmd

Certbot raportas sukcesan renovigon, la dosieroj sur la disko portas novajn datojn, kaj klientoj ankoraŭ renkontas la malnovan identecon. SoftEther tenas sian SSL-servilan atestilon en sia propra agordo je servila nivelo, do nova dosiero sur la disko ŝanĝas nenion ĝis la folia atestilo kaj ĝia ŝlosilo estos importitaj. La sekva sinsekvo kovras unu manan importon, envolvilon kiu ruliĝas post ĉiu renovigo, kaj kontrolon kiu legas kion la aŭskultilo efektive prezentas. Ĉiu paŝo lasas pruvojn, kiujn vi povas kompari post la sekva renovigo.

Renovigita dosiero ne ŝanĝas la servilan identecon

Eldonado kaj deplojo estas apartaj eventoj kun apartaj fiaskmanieroj. La ACME-kliento skribas dosierojn en linian dosierujon kaj registras sukceson; SoftEther daŭre uzas la atestilon, kiu laste estis ŝargita en ĝian agordon. Nula elira stato do priskribas la dosierojn, ne la servon, kaj la du povas malkonsenti dum neniu rigardas. Traktu la importon kiel la deplojan paŝon kaj la renovigon kiel ĝian enigon.

Tiu distingo ankaŭ klarigas la konfuzan duonan fiaskon: la malnova atestilo daŭre funkcias ĝis sia finiĝo, do komence nenio ŝajnas rompita. Kiam ĝi finiĝas, ĉiuj klientoj fiaskas samtempe, kio aspektas kiel interrompo anstataŭ preterlasita deploja paŝo. Kontroli la prezentitan identecon post ĉiu renovigo transformas tiun surprizon en rutinan observon.

Elektu la defion, kiu taŭgas por la aŭskultilo

La atestilo devas nomi la gastiganton, kiun klientoj kontrolas, do uzu la publikan DNS-nomon anstataŭ internan etikedon aŭ adreson. HTTP-01 postulas, ke la defio estu respondita sur pordo 80 dum momento, kio estas provizora aŭskultilo kaj neniam kialo movi la propran pordon de SoftEther. DNS-01 pruvas regadon per rikordo kaj tute ne bezonas envenantan HTTP.

Senpripensa renovigo signifas aŭtomatigitan DNS-integriĝon kun akreditaĵoj limigitaj al la unu zono, ne TXT-rikordon tajpitan mane ĉiun duan monaton. Ĵokero ŝanĝas la tipon de la defio, ne la bezonon de tiu aŭtomatigo. Decidu tion antaŭ ol la unua atestilo ekzistas, ĉar ŝanĝi la defitipon poste signifas tuŝi la klientan agordon kaj la fajroŝirmilon kune.

Tenu la artefaktojn ordaj dum vi estas ĉi tie. La folia atestilo kaj la mezaj atestiloj alvenas kiel apartaj dosieroj kaj kiel unu kombinita ĉena dosiero, la privata ŝlosilo estas denove aparta, kaj la importo bezonas la ĉenon kun ĝia kongrua ŝlosilo anstataŭ publika atestilo sola.

Importu la ĉenon je servila nivelo

Faru sekurkopion de la servila agordo kaj konfirmu, ke vi ankoraŭ povas atingi la administran interfacon antaŭ ol tuŝi la atestilon. Konektiĝu kiel servila administranto anstataŭ Virtual Hub-administranto, ĉar la atestilo apartenas al la servila objekto. Poste ŝargu la ĉenon kaj la ŝlosilon laŭ absoluta vojo, el dosieroj kiujn la konto rulanta la komandon povas legi. Notu, ke la vojoj estas absolutaj ĉar la komando solvas ilin el la labora dosierujo de tiu procezo, kiu rulis vpncmd:

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

Legu la eligon de la komando anstataŭ supozi sukceson, kaj poste relegu la ĉenon anstataŭ fidi la dosieron, kiun vi transdonis. La limo inter konstruaĵoj, kiuj importas tutan PEM-pakaĵon, kaj konstruaĵoj, kiuj prenas nur la unuan atestilon, ne estas dokumentita en unu loko, do la kontrolo decidas tion por la konstruaĵo antaŭ vi. Kalkulu la atestilojn, kiujn la aŭskultilo prezentas; folio sen mezaj atestiloj estas la subskribo de importanto, kiu konsumis nur la unuan blokon.

Tenu la importitan ŝlosilon legebla nur por la konto, kiu rulas la servilon, kaj tenu la administran pasvorton ekster la ŝelhistorio. Por ĉi tiu unua importo, tajpu la pasvorton ĉe la invito anstataŭ transdoni ĝin kiel komandan argumenton. Tiuj du kutimoj kostas nenion kaj forigas la plej kutiman manieron, per kiu atestila deplojo elfluigas ion, kion ĝi devus protekti. Faru tion antaŭ la unua importo, ne post ĝi.

Hoku la deplojon, ne la renovigon

Post kiam la mana importo funkcias, metu ĝuste tiujn paŝojn en malgrandan envolvilon kaj voku ĝin el la ACME-kliento post sukcesa renovigo. Certbot agordas RENEWED_LINEAGE kaj RENEWED_DOMAINS por la hoko, do la envolvilo povas agi pri unu atestilo en maŝino, kiu administras plurajn. Filtru laŭ la linio anstataŭ reagi al ĉiu renovigo sur la gastiganto. La envolvilo estas deploja kodo, kiu ruliĝas kun la privilegioj de la servilo, do revizuu ĝin kiel ĉiun alian skripton en tiu pozicio.

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

Hoko, kiu ruliĝas senpripense, bezonas sian propran protektitan akreditaĵan konservejon kaj fiaskan signalon, kiu atingas homon. Se la eldonado sukcesas kaj la importo fiaskas, ripetu la importon anstataŭ peti alian atestilon, ĉar dua peto kaŝas la deplojan difekton malantaŭ nova dosiero. La dokumentaro de Certbot pri renovigo klare diras, ke rulo, kiu ĝisdatigas nenion, estas normala rezulto, do la hoko estas tio, kio distingas la du.

Komparu la prezentitan ĉenon kun la dosiero

Legu la aŭskultilon, ne la diskon. Konektiĝu al la klientfronta pordo kun la servila nomo, kiun uzas la klientoj, poste komparu la fingrospuron kaj la liveritan ĉenon kun la linio, kiun la hoko instalas. Du komandoj kovras tion, kaj la unua ankaŭ montras, ĉu mezaj atestiloj entute alvenas:

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

Poste faru novan klientan konekton, ĉar sesioj establitaj antaŭ la importo estis aŭtentikigitaj kontraŭ la antaŭa identeco kaj pruvas nenion pri la nova. Se klientoj fiksas la malnovan folion, ili bezonas kunordigitan ĝisdatigon eĉ kiam la publika ĉeno validas, kaj tiu tasko apartenas al la sama runlibro kiel la renovigo. Inversa prokura servilo antaŭ la servo povas prezenti bonan atestilon dum la VPN-aŭskultilo ankoraŭ tenas la malnovan, kaj tial la kontrolo devas nomi la pordon, kiun klientoj efektive atingas. Registru la fingrospuron apud la renoviga dato, por ke la sekva komparo estu kontrolo kaj ne ago de memoro.