SoftEther ServerCertSet: de vernieuwde keten importeren met vpncmd

Certbot meldt een geslaagde vernieuwing, de bestanden op schijf dragen nieuwe datums, en clients treffen nog steeds de oude identiteit. SoftEther houdt zijn SSL-servercertificaat in zijn eigen configuratie op serverniveau, dus een nieuw bestand op schijf verandert niets totdat het blad en zijn sleutel zijn geïmporteerd. De volgorde hieronder behandelt één handmatige import, een wrapper die na elke vernieuwing draait, en een controle die leest wat de listener werkelijk presenteert. Elke stap laat bewijs achter dat u na de volgende vernieuwing kunt vergelijken.

Een vernieuwd bestand verandert de identiteit van de server niet

Uitgifte en uitrol zijn afzonderlijke gebeurtenissen met afzonderlijke faalwijzen. De ACME-client schrijft bestanden naar een lineage-map en registreert succes; SoftEther blijft het certificaat gebruiken dat het laatst in zijn configuratie is geladen. Een exitstatus van nul beschrijft dus de bestanden, niet de dienst, en die twee kunnen van mening verschillen zolang niemand kijkt. Behandel de import als de uitrolstap en de vernieuwing als de invoer ervan.

Dat onderscheid verklaart ook de verwarrende halve fout: het oude certificaat blijft werken tot het verloopt, dus in het begin lijkt niets kapot. Wanneer het verloopt, falen alle clients tegelijk, wat op een storing lijkt en niet op een gemiste uitrolstap. De gepresenteerde identiteit na elke vernieuwing controleren maakt die verrassing tot een routinewaarneming.

Kies de uitdaging die bij de listener past

Het certificaat moet de host noemen die clients verifiëren, dus gebruik de openbare DNS-naam in plaats van een intern label of een adres. HTTP-01 vereist dat de uitdaging even op poort 80 wordt beantwoord, wat een tijdelijke listener is en nooit een reden om SoftEthers eigen poort te verplaatsen. DNS-01 bewijst controle via een record en heeft helemaal geen inkomende HTTP nodig.

Onbeheerde vernieuwing betekent een geautomatiseerde DNS-integratie met inloggegevens die tot één zone beperkt zijn, niet een TXT-record dat elke twee maanden met de hand wordt getypt. Een wildcard verandert het type uitdaging, niet de noodzaak van die automatisering. Beslis dit voordat het eerste certificaat bestaat, want later van uitdagingstype wisselen betekent de clientconfiguratie en de firewall tegelijk aanraken.

Houd de artefacten op orde zolang u hier bent. Het blad en de tussenliggende certificaten komen als aparte bestanden en als één gecombineerd ketenbestand, de persoonlijke sleutel is weer apart, en de import heeft de keten met de bijbehorende sleutel nodig, niet een openbaar certificaat alleen.

Importeer de keten op serverniveau

Maak een back-up van de serverconfiguratie en bevestig dat u de beheerinterface nog bereikt voordat u het certificaat aanraakt. Verbind als serverbeheerder en niet als Virtual Hub-beheerder, omdat het certificaat bij het serverobject hoort. Laad daarna de keten en de sleutel met een absoluut pad, uit bestanden die het account dat de opdracht uitvoert kan lezen. Merk op dat de paden absoluut zijn omdat de opdracht ze oplost vanuit de werkmap van het proces dat vpncmd heeft uitgevoerd:

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

Lees de uitvoer van de opdracht in plaats van succes aan te nemen, en lees daarna de keten terug in plaats van het bestand te vertrouwen dat u hebt doorgegeven. De grens tussen builds die een volledige PEM-bundel importeren en builds die alleen het eerste certificaat nemen is niet op één plek gedocumenteerd, dus de controle beslist het voor de build voor u. Tel de certificaten die de listener presenteert; een blad zonder tussenliggende certificaten is de signatuur van een importeur die alleen het eerste blok heeft verbruikt.

Houd de geïmporteerde sleutel alleen leesbaar voor het account dat de server uitvoert, en houd het beheerwachtwoord buiten de shell-geschiedenis. Typ bij deze eerste import het wachtwoord bij de prompt in plaats van het als opdrachtargument door te geven. Die twee gewoonten kosten niets en verwijderen de meest voorkomende manier waarop een certificaaturitrol iets lekt dat het moest beschermen. Doe dat vóór de eerste import, niet erna.

Hang de uitrol eraan, niet de vernieuwing

Zodra de handmatige import werkt, zet u precies die stappen in een kleine wrapper en roept u die vanuit de ACME-client aan na een geslaagde vernieuwing. Certbot stelt RENEWED_LINEAGE en RENEWED_DOMAINS in voor de hook, zodat de wrapper op één certificaat kan werken op een machine die er meerdere beheert. Filter op de lineage in plaats van op elke vernieuwing op de host te reageren. De wrapper is uitrolcode die met de rechten van de server draait, dus beoordeel hem zoals elk ander script in die positie.

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

Een hook die onbeheerd draait heeft zijn eigen beschermde opslag voor inloggegevens nodig en een faalsignaal dat een mens bereikt. Als de uitgifte slaagt en de import mislukt, probeer de import opnieuw in plaats van een ander certificaat aan te vragen, want een tweede aanvraag verbergt het uitroldefect achter een nieuw bestand. De Certbot-documentatie over vernieuwen is duidelijk dat een run die niets bijwerkt een normaal resultaat is, dus de hook is wat de twee onderscheidt.

Vergelijk de gepresenteerde keten met het bestand

Lees de listener, niet de schijf. Verbind met de clientgerichte poort met de servernaam die de clients gebruiken, en vergelijk dan de vingerafdruk en de geleverde keten met de lineage die de hook heeft geïnstalleerd. Twee opdrachten dekken dat, en de eerste laat ook zien of tussenliggende certificaten überhaupt aankomen:

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

Maak daarna een nieuwe clientverbinding, want sessies die vóór de import zijn opgezet, zijn geauthenticeerd tegen de vorige identiteit en bewijzen niets over de nieuwe. Als clients het oude blad vastpinnen, hebben ze een gecoördineerde update nodig, zelfs wanneer de openbare keten geldig is, en die taak hoort in dezelfde runbook als de vernieuwing. Een reverse proxy voor de dienst kan een goed certificaat presenteren terwijl de VPN-listener nog het oude houdt, en daarom moet de controle de poort noemen die clients werkelijk bereiken. Noteer de vingerafdruk naast de vernieuwingsdatum, zodat de volgende vergelijking een controle is en geen daad van geheugen.