SoftEther ServerCertSet : importer la chaîne renouvelée avec vpncmd

Certbot signale un renouvellement réussi, les fichiers du disque portent de nouvelles dates, et les clients rencontrent toujours l'ancienne identité. SoftEther conserve son certificat SSL de serveur dans sa propre configuration au niveau du serveur, donc un nouveau fichier sur le disque ne change rien tant que le certificat feuille et sa clé ne sont pas importés. La séquence ci-dessous couvre un import manuel, un enveloppement exécuté après chaque renouvellement, et une vérification qui lit ce que l'écouteur présente réellement. Chaque étape laisse des preuves que vous pouvez comparer après le renouvellement suivant.

Un fichier renouvelé ne change pas l'identité du serveur

L'émission et le déploiement sont des événements distincts avec des modes de défaillance distincts. Le client ACME écrit des fichiers dans un répertoire de lignée et enregistre le succès ; SoftEther continue d'utiliser le certificat chargé en dernier dans sa configuration. Un code de sortie nul décrit donc les fichiers, pas le service, et les deux peuvent diverger tant que personne ne regarde. Traitez l'import comme l'étape de déploiement et le renouvellement comme son entrée.

Cette distinction explique aussi l'échec partiel déroutant : l'ancien certificat continue de fonctionner jusqu'à son expiration, donc rien ne semble cassé au début. Quand il expire, tous les clients échouent d'un coup, ce qui ressemble à une panne et non à une étape de déploiement manquée. Vérifier l'identité présentée après chaque renouvellement transforme cette surprise en observation de routine.

Choisissez le défi adapté à l'écouteur

Le certificat doit nommer l'hôte que les clients vérifient, donc utilisez le nom DNS public plutôt qu'une étiquette interne ou une adresse. HTTP-01 exige que le défi soit répondu sur le port 80 pendant un instant, ce qui est un écouteur temporaire et jamais une raison de déplacer le port propre à SoftEther. DNS-01 prouve le contrôle par un enregistrement et n'a besoin d'aucun HTTP entrant.

Le renouvellement sans surveillance suppose une intégration DNS automatisée avec des identifiants limités à une seule zone, pas un enregistrement TXT tapé à la main tous les deux mois. Un joker change le type de défi, pas le besoin de cette automatisation. Décidez-le avant que le premier certificat existe, car changer de type de défi plus tard signifie toucher ensemble la configuration du client et le pare-feu.

Gardez les artefacts en ordre pendant que vous êtes ici. Le certificat feuille et les intermédiaires arrivent en fichiers séparés et en un fichier de chaîne combiné, la clé privée est de nouveau séparée, et l'import a besoin de la chaîne avec sa clé correspondante, pas d'un certificat public seul.

Importez la chaîne au niveau du serveur

Sauvegardez la configuration du serveur et confirmez que vous atteignez encore l'interface de gestion avant de toucher au certificat. Connectez-vous en administrateur de serveur et non en administrateur de Virtual Hub, car le certificat appartient à l'objet serveur. Chargez ensuite la chaîne et la clé par un chemin absolu, depuis des fichiers que le compte exécutant la commande peut lire. Notez que les chemins sont absolus car la commande les résout depuis le répertoire de travail du processus qui a lancé vpncmd :

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

Lisez la sortie de la commande au lieu de supposer le succès, puis relisez la chaîne au lieu de faire confiance au fichier que vous avez fourni. La frontière entre les versions qui importent un paquet PEM entier et celles qui ne prennent que le premier certificat n'est pas documentée en un seul endroit, donc la vérification tranche pour la version devant vous. Comptez les certificats que l'écouteur présente ; une feuille sans intermédiaires est la signature d'un importateur qui n'a consommé que le premier bloc.

Gardez la clé importée lisible uniquement par le compte qui exécute le serveur, et gardez le mot de passe d'administration hors de l'historique du shell. Pour ce premier import, tapez le mot de passe à l'invite au lieu de le passer comme argument de commande. Ces deux habitudes ne coûtent rien et suppriment la façon la plus courante pour un déploiement de certificat de divulguer ce qu'il devait protéger. Faites-le avant le premier import, pas après.

Accrochez le déploiement, pas le renouvellement

Une fois l'import manuel au point, mettez exactement ces étapes dans un petit enveloppement et appelez-le depuis le client ACME après un renouvellement réussi. Certbot définit RENEWED_LINEAGE et RENEWED_DOMAINS pour le hook, donc l'enveloppement peut agir sur un certificat sur une machine qui en gère plusieurs. Filtrez sur la lignée au lieu de réagir à chaque renouvellement de l'hôte. L'enveloppement est du code de déploiement exécuté avec les privilèges du serveur, donc relisez-le comme tout autre script à cette place.

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

Un hook exécuté sans surveillance a besoin de son propre magasin d'identifiants protégé et d'un signal de défaillance qui atteint un humain. Si l'émission réussit et que l'import échoue, réessayez l'import au lieu de demander un autre certificat, car une seconde demande cache le défaut de déploiement derrière un fichier neuf. La documentation de renouvellement de Certbot indique clairement qu'une exécution qui ne met rien à jour est un résultat normal, donc le hook est ce qui distingue les deux.

Comparez la chaîne présentée au fichier

Lisez l'écouteur, pas le disque. Connectez-vous au port orienté clients avec le nom de serveur que les clients utilisent, puis comparez l'empreinte et la chaîne livrée à la lignée installée par le hook. Deux commandes suffisent, et la première montre aussi si les intermédiaires arrivent :

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

Faites ensuite une nouvelle connexion client, car les sessions établies avant l'import ont été authentifiées contre l'identité précédente et ne prouvent rien sur la nouvelle. Si les clients épinglent l'ancienne feuille, ils ont besoin d'une mise à jour coordonnée même quand la chaîne publique est valide, et cette tâche relève du même runbook que le renouvellement. Un proxy inverse devant le service peut présenter un bon certificat alors que l'écouteur VPN détient encore l'ancien, et c'est pourquoi la vérification doit nommer le port que les clients atteignent réellement. Notez l'empreinte à côté de la date de renouvellement, pour que la prochaine comparaison soit une vérification et non un acte de mémoire.