SoftEther ServerCertSet: import obnoveného řetězce pomocí vpncmd

Certbot hlásí úspěšné obnovení, soubory na disku nesou nová data a klienti se stále setkávají se starou identitou. SoftEther drží svůj SSL certifikát serveru ve vlastní konfiguraci na úrovni serveru, takže nový soubor na disku nic nezmění, dokud se neimportuje koncový certifikát a jeho klíč. Následující postup pokrývá jeden ruční import, obal, který se spouští po každém obnovení, a kontrolu, která čte, co listener skutečně předkládá. Každý krok zanechává důkazy, které můžete po příštím obnovení porovnat.

Obnovený soubor nemění identitu serveru

Vydání a nasazení jsou oddělené události s oddělenými režimy selhání. Klient ACME zapisuje soubory do adresáře linie a zaznamenává úspěch; SoftEther dál používá certifikát, který byl naposledy načten do jeho konfigurace. Nulový návratový stav proto popisuje soubory, ne službu, a obojí se může rozcházet, dokud se nikdo nedívá. Berte import jako krok nasazení a obnovení jako jeho vstup.

Tento rozdíl vysvětluje i matoucí poloviční selhání: starý certifikát funguje až do vypršení platnosti, takže zpočátku nic nevypadá rozbité. Když vyprší, selžou všichni klienti najednou, což vypadá jako výpadek, ne jako vynechaný krok nasazení. Kontrola předložené identity po každém obnovení mění toto překvapení v rutinní pozorování.

Vyberte výzvu, která sedí k listeneru

Certifikát musí pojmenovat hostitele, který klienti ověřují, takže použijte veřejné DNS jméno, ne interní označení nebo adresu. HTTP-01 vyžaduje, aby byla výzva chvíli zodpovězena na portu 80, což je dočasný listener a nikdy důvod přesouvat vlastní port SoftEtheru. DNS-01 prokazuje kontrolu pomocí záznamu a příchozí HTTP vůbec nepotřebuje.

Bezobslužné obnovování znamená automatizovanou integraci DNS s přihlašovacími údaji omezenými na jednu zónu, ne záznam TXT psaný ručně každé dva měsíce. Divoká karta mění typ výzvy, ne potřebu této automatizace. Rozhodněte to dřív, než existuje první certifikát, protože pozdější změna typu výzvy znamená sáhnout na konfiguraci klienta i firewall zároveň.

Udržujte artefakty v pořádku, dokud jste tady. Koncový certifikát a zprostředkující certifikáty přicházejí jako samostatné soubory a jako jeden sloučený soubor řetězce, soukromý klíč je opět zvlášť a import potřebuje řetězec s odpovídajícím klíčem, ne veřejný certifikát samotný.

Importujte řetězec na úrovni serveru

Zazálohujte konfiguraci serveru a ověřte, že se ještě dostanete na rozhraní pro správu, než se dotknete certifikátu. Připojte se jako správce serveru, ne jako správce Virtual Hubu, protože certifikát patří objektu serveru. Potom načtěte řetězec a klíč pomocí absolutní cesty, ze souborů, které účet spouštějící příkaz může číst. Všimněte si, že cesty jsou absolutní, protože je příkaz vyhodnocuje z pracovního adresáře procesu, který spustil vpncmd:

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

Čtěte výstup příkazu, místo abyste předpokládali úspěch, a potom řetězec přečtěte znovu, místo abyste věřili souboru, který jste předali. Hranice mezi buildy, které importují celý balík PEM, a buildy, které berou jen první certifikát, není zdokumentována na jednom místě, takže právě kontrola to pro build před vámi rozhodne. Spočítejte certifikáty, které listener předkládá; koncový certifikát bez zprostředkujících je podpisem importéru, který spotřeboval jen první blok.

Udržujte importovaný klíč čitelný jen pro účet, který spouští server, a držte správcovské heslo mimo historii shellu. Při tomto prvním importu napište heslo do výzvy, místo abyste ho předali jako argument příkazu. Tyto dva návyky nic nestojí a odstraňují nejběžnější způsob, jak nasazení certifikátu vyzradí něco, co mělo chránit. Udělejte to před prvním importem, ne po něm.

Zavěste nasazení, ne obnovení

Když ruční import funguje, dejte přesně tyto kroky do malého obalu a zavolejte ho z klienta ACME po úspěšném obnovení. Certbot pro hook nastavuje RENEWED_LINEAGE a RENEWED_DOMAINS, takže obal může jednat o jednom certifikátu na stroji, který jich spravuje několik. Filtrujte podle linie, místo abyste reagovali na každé obnovení na hostiteli. Obal je kód nasazení, který běží s oprávněními serveru, takže ho zkontrolujte jako každý jiný skript na tomto místě.

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

Hook, který běží bez dozoru, potřebuje vlastní chráněné úložiště přihlašovacích údajů a signál o selhání, který se dostane k člověku. Pokud vydání uspěje a import selže, zkuste import znovu, místo abyste žádali další certifikát, protože druhá žádost skryje vadu nasazení za novým souborem. Dokumentace Certbotu k obnovování jasně říká, že běh, který nic neaktualizuje, je normální výsledek, takže hook je to, co obojí rozliší.

Porovnejte předložený řetězec se souborem

Čtěte listener, ne disk. Připojte se k portu obrácenému ke klientům se jménem serveru, které klienti používají, a pak porovnejte otisk a dodaný řetězec s linií, kterou hook nainstaloval. Pokrývají to dva příkazy a první také ukáže, jestli zprostředkující certifikáty vůbec dorazí:

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

Pak vytvořte nové klientské připojení, protože relace navázané před importem byly autentizovány proti předchozí identitě a o nové nic nedokazují. Pokud klienti připínají starý koncový certifikát, potřebují koordinovanou aktualizaci, i když je veřejný řetězec platný, a tento úkol patří do stejného runbooku jako obnovení. Reverzní proxy před službou může předkládat dobrý certifikát, zatímco listener VPN stále drží starý, a proto kontrola musí pojmenovat port, který klienti skutečně dosáhnou. Zapište otisk vedle data obnovení, aby příští porovnání bylo kontrolou, a ne aktem paměti.