SoftEther ServerCertSet: uvoz obnovljene verige z vpncmd

Certbot poroča o uspešni obnovitvi, datoteke na disku nosijo nove datume, odjemalci pa še vedno srečujejo staro identiteto. SoftEther hrani svoj SSL-strežniški certifikat v lastni konfiguraciji na ravni strežnika, zato nova datoteka na disku ne spremeni ničesar, dokler nista uvožena list in njegov ključ. Spodnje zaporedje pokriva en ročni uvoz, ovoj, ki se izvaja po vsaki obnovitvi, in preverjanje, ki prebere, kaj poslušalec dejansko predstavi. Vsak korak pušča dokaze, ki jih lahko primerjate po naslednji obnovitvi.

Obnovljena datoteka ne spremeni identitete strežnika

Izdaja in uvajanje sta ločena dogodka z ločenimi načini odpovedi. Odjemalec ACME zapisuje datoteke v imenik linije in beleži uspeh; SoftEther še naprej uporablja certifikat, ki je bil nazadnje naložen v njegovo konfiguracijo. Ničelno izhodno stanje torej opisuje datoteke, ne storitve, in oba se lahko razhajata, dokler nihče ne gleda. Uvoz obravnavajte kot korak uvajanja in obnovitev kot njegov vhod.

Ta razlika pojasnjuje tudi zmedeno polovično napako: stari certifikat deluje do svojega izteka, zato sprva nič ne izgleda pokvarjeno. Ko poteče, vsi odjemalci odpovejo hkrati, kar izgleda kot izpad in ne kot zamujen korak uvajanja. Preverjanje predstavljene identitete po vsaki obnovitvi to presenečenje spremeni v rutinsko opazovanje.

Izberite izziv, ki ustreza poslušalcu

Certifikat mora imenovati gostitelja, ki ga odjemalci preverjajo, zato uporabite javno ime DNS in ne notranje oznake ali naslova. HTTP-01 zahteva, da je izziv za trenutek odgovorjen na vratih 80, kar je začasen poslušalec in nikoli razlog za premik lastnih vrat SoftEther. DNS-01 dokazuje nadzor z zapisom in vhodnega HTTP sploh ne potrebuje.

Obnovitev brez nadzora pomeni avtomatizirano integracijo DNS s poverilnicami, omejenimi na eno območje, ne zapisa TXT, ki se ročno vpiše vsaka dva meseca. Nadomestni znak spremeni vrsto izziva, ne potrebe po tej avtomatizaciji. Odločite se o tem, preden obstaja prvi certifikat, ker poznejša sprememba vrste izziva pomeni sočasno poseganje v konfiguracijo odjemalca in požarni zid.

Ohranjajte artefakte v redu, dokler ste tukaj. List in vmesni certifikati pridejo kot ločene datoteke in kot ena združena datoteka verige, zasebni ključ je spet ločen, uvoz pa potrebuje verigo z ujemajočim se ključem, ne javnega certifikata samega.

Uvozite verigo na ravni strežnika

Naredite varnostno kopijo konfiguracije strežnika in potrdite, da še vedno dosežete upravljalni vmesnik, preden se dotaknete certifikata. Povežite se kot skrbnik strežnika in ne kot skrbnik Virtual Hub, ker certifikat pripada strežniškemu objektu. Nato naložite verigo in ključ po absolutni poti, iz datotek, ki jih lahko bere račun, ki izvaja ukaz. Upoštevajte, da so poti absolutne, ker jih ukaz razreši iz delovnega imenika procesa, ki je zagnal vpncmd:

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

Preberite izhod ukaza, namesto da predpostavite uspeh, in nato znova preberite verigo, namesto da zaupate datoteki, ki ste jo predali. Meja med gradnjami, ki uvozijo celoten paket PEM, in gradnjami, ki vzamejo le prvi certifikat, ni dokumentirana na enem mestu, zato prav preverjanje to odloči za gradnjo pred vami. Preštejte certifikate, ki jih poslušalec predstavi; list brez vmesnih je podpis uvoznika, ki je porabil le prvi blok.

Ohranite uvožen ključ berljiv le za račun, ki izvaja strežnik, in hranite skrbniško geslo zunaj zgodovine lupine. Pri tem prvem uvozu vnesite geslo v poziv, namesto da bi ga posredovali kot argument ukaza. Ti dve navadi nič ne staneta in odstranita najpogostejši način, kako uvajanje certifikata razkrije nekaj, kar bi moralo zaščititi. Storite to pred prvim uvozom, ne po njem.

Pripnite uvajanje, ne obnovitve

Ko ročni uvoz deluje, dajte natanko te korake v majhen ovoj in ga pokličite iz odjemalca ACME po uspešni obnovitvi. Certbot za hook nastavi RENEWED_LINEAGE in RENEWED_DOMAINS, zato lahko ovoj deluje na enem certifikatu na stroju, ki jih upravlja več. Filtrirajte po liniji, namesto da bi se odzivali na vsako obnovitev na gostitelju. Ovoj je koda za uvajanje, ki teče z privilegiji strežnika, zato ga pregledajte kot vsako drugo skripto na tem mestu.

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

Hook, ki teče brez nadzora, potrebuje svoje zaščiteno shrambo poverilnic in signal o napaki, ki doseže človeka. Če izdaja uspe, uvoz pa ne, poskusite uvoz znova, namesto da zahtevate drug certifikat, ker druga zahteva skrije napako uvajanja za novo datoteko. Dokumentacija Certbota o obnovitvi jasno navaja, da je zagon, ki ničesar ne posodobi, običajen izid, zato hook loči oba primera.

Primerjajte predstavljeno verigo z datoteko

Berite poslušalec, ne disk. Povežite se na vrata, obrnjena k odjemalcem, z imenom strežnika, ki ga uporabljajo odjemalci, in nato primerjajte prstni odtis ter dostavljeno verigo z linijo, ki jo je namestil hook. Dva ukaza to pokrijeta, prvi pa pokaže tudi, ali vmesni certifikati sploh prispejo:

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

Nato ustvarite novo odjemalsko povezavo, ker so bile seje, vzpostavljene pred uvozom, overjene proti prejšnji identiteti in o novi ne dokazujejo ničesar. Če odjemalci pripnejo stari list, potrebujejo usklajeno posodobitev, tudi ko je javna veriga veljavna, in ta naloga sodi v isti runbook kot obnovitev. Povratni posrednik pred storitvijo lahko predstavi dober certifikat, medtem ko poslušalec VPN še vedno drži starega, zato mora preverjanje imenovati vrata, ki jih odjemalci dejansko dosežejo. Zapišite prstni odtis ob datumu obnovitve, da bo naslednja primerjava preverjanje in ne dejanje spomina.