SoftEther ServerCertSet: importera den förnyade kedjan med vpncmd

Certbot rapporterar en lyckad förnyelse, filerna på disken har nya datum, och klienterna möter fortfarande den gamla identiteten. SoftEther håller sitt SSL-servercertifikat i sin egen konfiguration på servernivå, så en ny fil på disken ändrar ingenting förrän bladet och dess nyckel har importerats. Sekvensen nedan täcker en manuell import, ett omslag som körs efter varje förnyelse, och en kontroll som läser vad lyssnaren faktiskt presenterar. Varje steg lämnar bevis som du kan jämföra efter nästa förnyelse.

En förnyad fil ändrar inte serverns identitet

Utfärdande och distribution är separata händelser med separata felmoder. ACME-klienten skriver filer till en lineage-katalog och registrerar framgång; SoftEther fortsätter att använda det certifikat som senast laddades in i konfigurationen. En noll-exitstatus beskriver därför filerna, inte tjänsten, och de två kan vara oense så länge ingen tittar. Behandla importen som distributionsteget och förnyelsen som dess indata.

Skillnaden förklarar också det förvirrande halvfaillet: det gamla certifikatet fungerar till det löper ut, så ingenting ser trasigt ut i början. När det löper ut misslyckas alla klienter samtidigt, vilket ser ut som ett avbrott och inte som ett förbisett distributionsteg. Att kontrollera den presenterade identiteten efter varje förnyelse gör den överraskningen till en rutinmässig observation.

Välj den utmaning som passar lyssnaren

Certifikatet måste namnge värden som klienterna verifierar, så använd det publika DNS-namnet i stället för en intern etikett eller en adress. HTTP-01 kräver att utmaningen besvaras på port 80 en stund, vilket är en tillfällig lyssnare och aldrig en anledning att flytta SoftEthers egen port. DNS-01 bevisar kontroll via en post och behöver ingen inkommande HTTP alls.

Övervakad förnyelse betyder en automatiserad DNS-integration med autentiseringsuppgifter begränsade till en zon, inte en TXT-post som skrivs för hand varannan månad. Ett jokertecken ändrar utmaningstypen, inte behovet av den automatiseringen. Bestäm detta innan det första certifikatet finns, eftersom att byta utmaningstyp senare innebär att röra klientkonfigurationen och brandväggen samtidigt.

Håll artefakterna i ordning medan du är här. Bladet och mellancertifikaten kommer som separata filer och som en kombinerad kedjefil, den privata nyckeln är åter separat, och importen behöver kedjan med tillhörande nyckel, inte ett publikt certifikat ensamt.

Importera kedjan på servernivå

Ta en säkerhetskopia av serverkonfigurationen och bekräfta att du fortfarande når administrationsgränssnittet innan du rör certifikatet. Anslut som serveradministratör och inte som Virtual Hub-administratör, eftersom certifikatet tillhör serverobjektet. Ladda sedan kedjan och nyckeln med absolut sökväg, från filer som kontot som kör kommandot kan läsa. Notera att sökvägarna är absoluta eftersom kommandot löser dem från arbetskatalogen för den process som körde vpncmd:

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

Läs kommandots utdata i stället för att anta framgång, och läs sedan tillbaka kedjan i stället för att lita på filen du gav. Gränsen mellan byggen som importerar hela PEM-paketet och byggen som bara tar det första certifikatet är inte dokumenterad på ett ställe, så kontrollen är det som avgör det för bygget framför dig. Räkna certifikaten som lyssnaren presenterar; ett blad utan mellancertifikat är signaturen för en importör som bara förbrukade det första blocket.

Håll den importerade nyckeln läsbar endast för kontot som kör servern, och håll administrationslösenordet utanför skalhistoriken. Vid denna första import skriver du lösenordet vid prompten i stället för att skicka det som ett kommandoparameter. De två vanorna kostar ingenting och tar bort det vanligaste sättet som en certifikatdistribution läcker något den skulle skydda. Gör det före den första importen, inte efter.

Haka på distributionen, inte förnyelsen

När den manuella importen fungerar, lägg exakt de stegen i ett litet omslag och anropa det från ACME-klienten efter en lyckad förnyelse. Certbot sätter RENEWED_LINEAGE och RENEWED_DOMAINS för hooken, så omslaget kan agera på ett certifikat på en maskin som administrerar flera. Filtrera på lineage i stället för att reagera på varje förnyelse på värden. Omslaget är distributionskod som körs med serverns rättigheter, så granska det som vilket annat skript som helst i den positionen.

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

En hook som körs utan övervakning behöver sitt eget skyddade lager för autentiseringsuppgifter och en felsignal som når en människa. Om utfärdandet lyckas och importen misslyckas, försök importera igen i stället för att begära ett nytt certifikat, eftersom en andra begäran döljer distributionsfelet bakom en ny fil. Certbots dokumentation om förnyelse är tydlig med att en körning som inte uppdaterar något är ett normalt resultat, så hooken är det som skiljer de två åt.

Jämför den presenterade kedjan med filen

Läs lyssnaren, inte disken. Anslut till den klientvända porten med servernamnet som klienterna använder, och jämför sedan fingeravtrycket och den levererade kedjan med den lineage som hooken installerade. Två kommandon täcker det, och det första visar också om mellancertifikat kommer överhuvudtaget:

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

Skapa sedan en ny klientanslutning, eftersom sessioner som upprättades före importen autentiserades mot den tidigare identiteten och inte bevisar något om den nya. Om klienter fäster det gamla bladet, behöver de en samordnad uppdatering även när den publika kedjan är giltig, och den uppgiften hör till samma runbook som förnyelsen. En omvänd proxy framför tjänsten kan presentera ett bra certifikat medan VPN-lyssnaren fortfarande håller det gamla, och därför måste kontrollen namnge den port som klienterna faktiskt når. Anteckna fingeravtrycket bredvid förnyelsedatumet, så att nästa jämförelse är en kontroll och inte en minneshandling.