SoftEther ServerCertSet: uvezite obnovljeni lanac pomoću vpncmd
Obnovljena datoteka ne mijenja identitet SoftEther servera. Uvezite lanac pomoću ServerCertSet, zakačite korak objavljivanja i pročitajte listener.
Certbot javlja uspješnu obnovu, datoteke na disku nose nove datume, a klijenti i dalje susreću stari identitet. SoftEther drži svoj SSL certifikat servera u vlastitoj konfiguraciji na razini servera, pa nova datoteka na disku ne mijenja ništa dok se lisni certifikat i njegov ključ ne uvezu. Slijed ispod pokriva jedno ručno uvoženje, omotač koji se pokreće nakon svake obnove i provjeru koja čita šta listener zaista predstavlja. Svaki korak ostavlja dokaze koje možete uporediti nakon sljedeće obnove.
Obnovljena datoteka ne mijenja identitet servera
Izdavanje i objavljivanje su odvojeni događaji s odvojenim načinima kvara. ACME klijent upisuje datoteke u direktorij loze i bilježi uspjeh; SoftEther nastavlja koristiti certifikat koji je posljednji učitan u njegovu konfiguraciju. Zato nulti izlazni status opisuje datoteke, a ne uslugu, i to dvoje se mogu razilaziti sve dok niko ne gleda. Tretirajte uvoz kao korak objavljivanja, a obnovu kao njegov ulaz.
Ta razlika objašnjava i zbunjujući polovični neuspjeh: stari certifikat nastavlja raditi do isteka, pa na početku ništa ne izgleda pokvareno. Kada istekne, svi klijenti padaju odjednom, što izgleda kao prekid rada, a ne kao propušten korak objavljivanja. Provjera predstavljenog identiteta nakon svake obnove pretvara to iznenađenje u rutinsko opažanje.
Odaberite izazov koji odgovara listeneru
Certifikat mora imenovati host koji klijenti provjeravaju, pa koristite javno DNS ime, a ne internu oznaku ili adresu. HTTP-01 zahtijeva da se na izazov nakratko odgovori na portu 80, što je privremeni listener i nikada razlog da pomjerite vlastiti port SoftEthera. DNS-01 dokazuje kontrolu putem zapisa i uopće ne treba dolazni HTTP.
Nadzirana obnova znači automatiziranu DNS integraciju s vjerodajnicama ograničenim na jednu zonu, a ne TXT zapis koji se ručno upisuje svaka dva mjeseca. Wildcard mijenja vrstu izazova, ne potrebu za tom automatizacijom. Odlučite to prije nego postoji prvi certifikat, jer kasnija promjena vrste izazova znači dirati klijentsku konfiguraciju i firewall zajedno.
Držite artefakte uredno dok ste ovdje. Lisni certifikat i posrednički dolaze kao odvojene datoteke i kao jedna spojena datoteka lanca, privatni ključ je opet odvojen, a uvoz traži lanac s odgovarajućim ključem, a ne javni certifikat sam po sebi.
Uvezite lanac na razini servera
Napravite sigurnosnu kopiju konfiguracije servera i potvrdite da još možete doći do upravljačkog interfejsa prije nego dirnete certifikat. Povežite se kao administrator servera, a ne kao administrator Virtual Huba, jer certifikat pripada objektu servera. Zatim učitajte lanac i ključ po apsolutnoj putanji, iz datoteka koje račun koji pokreće naredbu može čitati. Imajte na umu da su putanje apsolutne jer ih naredba razrješava iz radnog direktorija procesa koji je pokrenuo vpncmd:
ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pemPročitajte izlaz naredbe umjesto da pretpostavite uspjeh, a zatim pročitajte lanac ponovo umjesto da vjerujete datoteci koju ste predali. Granica između buildova koji uvoze cijeli PEM paket i buildova koji uzimaju samo prvi certifikat nije dokumentirana na jednom mjestu, pa provjera rješava stvar za build pred vama. Prebrojite certifikate koje listener predstavlja; lisni bez posredničkih potpis je uvoznika koji je potrošio samo prvi blok.
Držite uvezeni ključ čitljivim samo za račun koji pokreće server i držite upravljačku lozinku izvan historije ljuske. Za ovaj prvi uvoz upišite lozinku na upitu umjesto da je predate kao argument naredbe. Te dvije navike ništa ne koštaju i uklanjaju najčešći način na koji objavljivanje certifikata oda nešto što je trebalo zaštititi. Uradite to prije prvog uvoza, ne poslije.
Zakačite objavljivanje, a ne obnovu
Kada ručni uvoz proradi, stavite baš te korake u mali omotač i pozovite ga iz ACME klijenta nakon uspješne obnove. Certbot postavlja RENEWED_LINEAGE i RENEWED_DOMAINS za hook, pa omotač može djelovati na jedan certifikat na mašini koja upravlja više njih. Filtrirajte po lozi umjesto da reagirate na svaku obnovu na hostu. Omotač je kod za objavljivanje koji radi s privilegijama servera, pa ga pregledajte kao i svaku drugu skriptu na tom mjestu.
certbot renew --deploy-hook /usr/local/sbin/softether-deploy.shHook koji radi bez nadzora treba vlastito zaštićeno spremište vjerodajnica i signal kvara koji stigne do čovjeka. Ako izdavanje uspije, a uvoz ne uspije, pokušajte uvoz ponovo umjesto da zatražite drugi certifikat, jer drugi zahtjev krije nedostatak objavljivanja iza nove datoteke. Certbot dokumentacija o obnovi jasno kaže da je pokretanje koje ništa ne ažurira normalan ishod, pa hook razlikuje to dvoje.
Uporedite predstavljeni lanac s datotekom
Čitajte listener, a ne disk. Povežite se na port okrenut klijentima s imenom servera koje klijenti koriste, pa uporedite otisak i dostavljeni lanac s lozom koju je hook instalirao. Dvije naredbe to pokrivaju, a prva pokazuje i dolaze li posrednički certifikati uopće:
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 -sha256Zatim uspostavite novu klijentsku vezu, jer su sesije uspostavljene prije uvoza autentificirane prema prethodnom identitetu i ne dokazuju ništa o novom. Ako klijenti prikucaju stari lisni certifikat, potrebno im je koordinirano ažuriranje čak i kada je javni lanac valjan, a taj zadatak pripada istom runbooku kao i obnova. Obrnuti proxy ispred usluge može predstaviti dobar certifikat dok VPN listener još drži stari, i zato provjera mora imenovati port koji klijenti zaista dosežu. Zabilježite otisak uz datum obnove, da sljedeće poređenje bude provjera, a ne čin pamćenja.