3,072
edits
Changes
Jump to navigation
Jump to search
Line 348:
Line 348: − ==Sauvegarde == − Votre certificat, votre clé privée et d'autres informations importantes sont stockés dans /etc/dehydrated, ce qui n'est pas inclus dans les routines de sauvegarde normale du serveur KOOZALI SME. Assurez-vous d'ajouter ce répertoire à vos sauvegardes. Voir, par exemple, [[Backup with dar#Adding_Files_and_Directories|Sauvegardes avec dar]] si vous utilisez la fonction de sauvegarde de poste de travail. − Assurez-vous que le « / » de début dans /etc/dehydrated est supprimé lorsque vous créez votre fichier d'inclusion. Sinon, des erreurs d'analyse se produisent. − − Si vous utilisez Affa pour la sauvegarde, ajoutez : − − Include=/etc/dehydrated − − au fichier de configuration d'Affa. − − − ==Sujets avancés== − ===Obtention de certificats pour d'autres serveurs=== − Le client « dehydrated » peut être utilisé pour obtenir des certificats pour d'autres serveurs de votre réseau, si les noms d'hôte sont résolus (depuis l'extérieur de votre réseau) vers votre serveur SME. Voici comment procéder en utilisant la contribution smeserver-letsencrypt. − − ====Hôtes et domaines==== − {{Note box|type=Note : | pour autant que je (ReetP) sache, cette section n'est pas nécessaire. Vous devriez simplement être en mesure de définir un hôte avec « HostType local » et une adresse InternalIP comme activation de letsencryptSSLcert, puis régénérer domains.txt.}} − − Vous devrez créer deux fragments de modèle : un pour ajouter votre nom d'hôte à /etc/dehydrated/domains.txt, et le second pour gérer le certificat une fois qu'il est généré. Pour créer le premier, faites : − − mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt − nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname − − Vous pouvez remplacer «Hostname» dans «15Hostname» par un élément descriptif de l'hôte pour lequel vous voulez obtenir un certificat. Si vous souhaitez plusieurs certificats supplémentaires, créez des fragments distincts pour chacun. Dans le fichier, entrez simplement le nom de domaine complet du système : − − nom_d_hote.domaine − − Puis Ctrl-X pour quitter, Y pour sauvegarder. − − ====Déploiement du script d'accrochage==== − − Le deuxième fragment de modèle sera une partie du script d'accrochage, ainsi le client « dehydrated » sait quoi faire avec ce certificat. Cela doit être présent, sinon « dehydrated » configurera votre serveur SME pour qu'il utilise ce certificat plutôt que le certificat pour le serveur SME. − − mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/ − nano -w 05deploy_cert_hostname − − Comme ci-dessus, remplacez « hostname » par quelque chose qui décrit l'hôte auquel ce script s'appliquera. La partie numérique peut être modifiée, mais DOIT être inférieure à 10. − − Au minimum, ce fragment devra reconnaître qu'il est appelé pour un certificat autre que le certificat du serveur principal et devra s'arrêter afin d'empêcher les parties ultérieures du script d'installer ce certificat en tant que certificat du serveur principal. La forme minimale de ce fragment serait : − − { − use strict; − use warnings; − use esmith::ConfigDB; − − my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB"); − − my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled'; − − if ( $letsencryptStatus ne 'disabled' ) { − − $OUT .=<<'_EOF'; − if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then − echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com − exit 0 − fi − _EOF − − } − } − − Selon les caractéristiques de l'autre système, ce script peut cependant installer le certificat sur ce système. Le fragment suivant copiera les fichiers du certificat sur un système Linux distant exécutant Apache pour le serveur Web et rechargera Apache pour qu'il commence à utiliser le nouveau certificat : − − { − use strict; − use warnings; − use esmith::ConfigDB; − − my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB"); − − my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled'; − − if ( $letsencryptStatus ne 'disabled' ) { − − $OUT .=<<'_EOF'; − if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then − KEY=$3 − CERT=$4 − CHAIN=$6 − scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt − scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key − scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt − ssh root@pbx "/sbin/service httpd reload" − echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld − exit 0 − fi − _EOF − − } − } − − Le fragment suivant installe le nouveau certificat sur un hôte Proxmox VE : − − { − use strict; − use warnings; − use esmith::ConfigDB; − − my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB"); − − my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' ) || 'disabled'; − − if ( $letsencryptStatus ne 'disabled' ) { − − $OUT .=<<'_EOF'; − if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then − KEY=$3 − CHAIN=$5 − scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key − scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem − ssh root@pve "systemctl restart pveproxy" − echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld − exit 0 − fi − _EOF − − } − } − − Une fois que vous avez créé les fragments de modèle, développez les modèles et exécutez « dehydrated » pour générer les certificats : − − signal-event console-save − dehydrated -c − − Ces certificats seront automatiquement renouvelés, tout comme le certificat du serveur principal. − − === Obtenir des certificats pour un serveur KOOZALI SME privé === − Comme indiqué ci-dessus dans la section prérequis, votre serveur SME doit être normalement accessible depuis Internet afin que les serveurs de Let's Encrypt puissent valider que vous le contrôlez. Toutefois, si votre serveur SME n'est pas accessible depuis Internet, la contribution smeserver-letsencrypt fournit une méthode permettant de valider le contrôle de domaine. Pour utiliser cette méthode, les conditions suivantes doivent être remplies : − * le nom d'hôte de votre serveur SME interne (exemple: interne.mon-domaine.com) résout, sur l'Internet public, via une adresse IP valide ; − * l'hôte auquel interne.mon-domaine.com résout (exemple: passerelle.mon-domaine.com) dispose d'un serveur Web actif sur le port 80 ; − * l'utilisateur root de interne.mon-domaine.com peut se connecter à passerelle.mon-domaine.com via SSH sans entrer de mot de passe (c'est-à-dire que vous avez configuré l'authentification par clé publique SSH). − − Cette méthode utilise un script simple inclus dans la contribution smeserver-letsencrypt, qui requiert que quatre entrées d'une base de données soient définies : − − config setprop letsencrypt hookScript enabled − config setprop letsencrypt host '''passerelle.mon-domaine.com''' − config setprop letsencrypt user '''root''' − config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''' − signal-event console-save − − Les parties en gras ci-dessus doivent être modifiées pour correspondre à votre situation ; la variable « path » devrait être l'emplacement du système de fichiers que l'hôte passerelle.mon-domaine.com mettra à disposition, comme /.well-known/acme-challenge/. Lorsque « dehydrated » crée le fichier de challenge, il le transfère via scp vers user@host: path/, puis autorise le serveur Let's Encrypt à valider. Une fois la validation effectuée, le script supprime le fichier de challenge de user@host:path/.
no edit summary
status=enabled
status=enabled
= Bogues =
= Bogues =