Letsencrypt/Advanced/fr
Cette page provient de la page originale Letsencrypt/fr pour supprimer ce qui n'est pas lié à la contribution. Vous pouvez retrouver ici le travail original qui a conduit à la contribution et qui permet une installation manuelle, et quelques configurations avancées.
La plupart de ces sujets fonctionnaient pour SME9, et pourraient ne pas être encore opérationnels pour SME10.
Imposer le SSL
Que vous ayez utilisé la contribution ou que vous ayez configuré « dehydrated » manuellement, vous souhaiterez probablement configurer votre serveur pour forcer les connexions Web sécurisées. Pour les baies d'informations (i-bays), vous pouvez le faire en utilisant la page du gestionnaire du serveur ou en utilisant une commande shell. Pour la baie principale (Primary), vous devez utiliser la commande shell :
db accounts setprop {accountname} SSL enabled
ou
db accounts setprop Primary SSL enabled
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, 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.
Lorsque vous utilisez la sauvegarde du gestionnaire de serveur (dar), 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.
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
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/.
