SoftEther ServerCertSet: importare la catena rinnovata con vpncmd

Certbot segnala un rinnovo riuscito, i file sul disco portano nuove date e i client incontrano ancora la vecchia identità. SoftEther tiene il certificato SSL del server nella propria configurazione a livello di server, quindi un nuovo file sul disco non cambia nulla finché il certificato foglia e la sua chiave non vengono importati. La sequenza seguente copre un'importazione manuale, un wrapper che gira dopo ogni rinnovo e un controllo che legge ciò che il listener presenta davvero. Ogni passo lascia prove che potete confrontare dopo il rinnovo successivo.

Un file rinnovato non cambia l'identità del server

Emissione e distribuzione sono eventi separati con modi di fallire separati. Il client ACME scrive i file in una directory di lineage e registra il successo; SoftEther continua a usare il certificato caricato per ultimo nella sua configurazione. Uno stato di uscita zero descrive quindi i file, non il servizio, e i due possono divergere finché nessuno guarda. Trattate l'importazione come passo di distribuzione e il rinnovo come il suo input.

Questa distinzione spiega anche il confuso mezzo fallimento: il vecchio certificato continua a funzionare fino alla scadenza, quindi all'inizio nulla sembra rotto. Quando scade, tutti i client falliscono insieme, il che sembra un'interruzione e non un passo di distribuzione mancato. Controllare l'identità presentata dopo ogni rinnovo trasforma quella sorpresa in un'osservazione di routine.

Scegliete la sfida adatta al listener

Il certificato deve nominare l'host che i client verificano, quindi usate il nome DNS pubblico invece di un'etichetta interna o di un indirizzo. HTTP-01 richiede che la sfida venga risposta sulla porta 80 per un istante, il che è un listener temporaneo e mai un motivo per spostare la porta di SoftEther. DNS-01 dimostra il controllo tramite un record e non richiede alcun HTTP in ingresso.

Il rinnovo senza sorveglianza significa un'integrazione DNS automatizzata con credenziali limitate a una sola zona, non un record TXT digitato a mano ogni due mesi. Un carattere jolly cambia il tipo di sfida, non la necessità di quell'automazione. Decidetelo prima che esista il primo certificato, perché cambiare tipo di sfida più avanti significa toccare insieme la configurazione del client e il firewall.

Tenete in ordine gli artefatti finché siete qui. Il certificato foglia e gli intermedi arrivano come file separati e come un unico file di catena combinato, la chiave privata è di nuovo separata, e l'importazione richiede la catena con la sua chiave corrispondente, non un certificato pubblico da solo.

Importate la catena a livello di server

Fate un backup della configurazione del server e confermate di raggiungere ancora l'interfaccia di gestione prima di toccare il certificato. Collegatevi come amministratore del server e non come amministratore del Virtual Hub, perché il certificato appartiene all'oggetto server. Poi caricate la catena e la chiave con percorso assoluto, da file che l'account che esegue il comando può leggere. Notate che i percorsi sono assoluti perché il comando li risolve dalla directory di lavoro del processo che ha eseguito vpncmd:

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

Leggete l'output del comando invece di dare per scontato il successo, poi rileggete la catena invece di fidarvi del file che avete passato. Il confine tra build che importano un intero bundle PEM e build che prendono solo il primo certificato non è documentato in un solo posto, quindi è il controllo a deciderlo per la build che avete davanti. Contate i certificati che il listener presenta; una foglia senza intermedi è la firma di un importatore che ha consumato solo il primo blocco.

Tenete la chiave importata leggibile solo all'account che esegue il server, e tenete la password di gestione fuori dalla cronologia della shell. Per questa prima importazione, digitate la password al prompt invece di passarla come argomento del comando. Queste due abitudini non costano nulla e rimuovono il modo più comune con cui una distribuzione di certificati rivela qualcosa che doveva proteggere. Fatelo prima della prima importazione, non dopo.

Agganciate la distribuzione, non il rinnovo

Una volta che l'importazione manuale funziona, mettete esattamente quei passi in un piccolo wrapper e chiamatelo dal client ACME dopo un rinnovo riuscito. Certbot imposta RENEWED_LINEAGE e RENEWED_DOMAINS per l'hook, così il wrapper può agire su un certificato su una macchina che ne gestisce diversi. Filtrate sul lineage invece di reagire a ogni rinnovo sull'host. Il wrapper è codice di distribuzione che gira con i privilegi del server, quindi riesaminatelo come qualsiasi altro script in quella posizione.

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

Un hook che gira senza sorveglianza ha bisogno del proprio archivio protetto di credenziali e di un segnale di fallimento che raggiunga una persona. Se l'emissione riesce e l'importazione fallisce, ritentate l'importazione invece di chiedere un altro certificato, perché una seconda richiesta nasconde il difetto di distribuzione dietro un file nuovo. La documentazione di Certbot sul rinnovo è chiara nel dire che un'esecuzione che non aggiorna nulla è un esito normale, quindi è l'hook a distinguere i due casi.

Confrontate la catena presentata con il file

Leggete il listener, non il disco. Collegatevi alla porta rivolta ai client con il nome del server che usano i client, poi confrontate l'impronta e la catena consegnata con il lineage installato dall'hook. Due comandi bastano, e il primo mostra anche se gli intermedi arrivano:

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

Poi fate una nuova connessione client, perché le sessioni stabilite prima dell'importazione sono state autenticate con l'identità precedente e non provano nulla sulla nuova. Se i client fissano la vecchia foglia, hanno bisogno di un aggiornamento coordinato anche quando la catena pubblica è valida, e quel compito appartiene allo stesso runbook del rinnovo. Un proxy inverso davanti al servizio può presentare un buon certificato mentre il listener VPN tiene ancora il vecchio, ed è per questo che il controllo deve nominare la porta che i client raggiungono davvero. Annotate l'impronta accanto alla data di rinnovo, così il confronto successivo è un controllo e non un atto di memoria.