3,069
edits
Changes
Jump to navigation
Jump to search
Line 12:
Line 12: − + − Your certificate, private key, and other important information are stored in /etc/dehydrated, which is not included in the standard SME Server backup routines. Make sure to add this directory to your backups. See, e.g., [[Backup with dar#Adding_Files_and_Directories|Backup with dar]] if you're using the workstation backup feature. If using Affa for backup, add+ + + + + − to the Affa configuration file. When using the Server-manager backup (dar) make sure the leading "/" in /etc/dehydrated is removed when you make your include file. Otherwise parse errors occur. + + + + + + + + + + + + − ==Advanced Topics== − ===Obtaining certificates for other servers=== − The dehydrated client can be used to obtain certificates for other servers on your network, if the hostnames resolve (from outside your network) to your SME Server. Here's how to do this using the smeserver-letsencrypt contrib. − ====Hosts and Domains==== − {{Note box| This section is not necessary as far as I am aware. You should just be able to set a host with "HostType local" and an InternalIP address as letsencryptSSLcert enabled and then regenerate domains.txt}} − You'll need to create two template fragments: one to add your hostname to /etc/dehydrated/domains.txt, and the second to handle the certificate once it's generated. To create the first, do − You can replace "Hostname" in "15Hostname" with something that's descriptive of the host you're obtaining a certificate for. If you want more than one additional certificate, create separate fragments for each one. In the file, just enter the fully-qualified domain name of the system:+ − hostname.domain.tld + − Then Ctrl-X to exit, Y to save.+ − + − The second template fragment will be a portion of the hook script, so the dehydrated client knows what to do with this certificate. This must be present, otherwise dehydrated will configure your SME server to use this certificate rather than the certificate for the SME Server.+ + + + + + + + + − As above, replace "hostname" with something that describes the host that this script will apply to. The numeric portion can be changed, but MUST be less than 10. − At a minimum, this fragment will need to recognize that it's being called for a certificate other than the main server certificate, and exit in order to prevent later portions of the script from installing that certificate as the main server certificate. The minimal form of this fragment would be:+ + + + Line 56:
Line 75: − Depending on the characteristics of the other system, though, this script may be able to install the certificate on that system. The following fragment would copy the certificate files to a remote Linux system running Apache for the web server, and reload Apache to get it to begin using the new certificate:+ + + Line 84:
Line 105: − The following fragment would install the new certificate on a Proxmox VE host:+ + + Line 110:
Line 133: − Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:+ + + − These certificates will be automatically renewed, just like the main server certificate.+ − + − As noted above in the prerequisites section, your SME Server must ordinarily be accessible from the Internet so that the Let's Encrypt servers can validate that you control it. However, if your SME Server is not accessible from the Internet, the smeserver-letsencrypt contrib provides a method that can be used to validate domain control. In order to use this method, the following conditions must be true:+ − + − + − + − This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:+ + + + + + − + − The parts in bold above should be changed to match your situation; the path variable should be the filesystem location that external.mydomain.tld serves as /.well-known/acme-challenge/ . When dehydrated creates the challenge file, it will transfer it via scp to user@host:path/, and then allow the Let's Encrypt server to validate. Once validation is accomplished, the script will remove the challenge file from user@host:path/+ +
Letsencrypt/Advanced/fr (view source)
Revision as of 19:49, 10 September 2022
, 19:49, 10 September 2022no edit summary
db accounts setprop Primary SSL enabled
db accounts setprop Primary SSL enabled
==Backup==
==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
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====
{{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
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname
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 :
====Hook Script deployment====
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/
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/
nano -w 05deploy_cert_hostname
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 strict;
}
}
}
}
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 strict;
}
}
}
}
Le fragment suivant installe le nouveau certificat sur un hôte Proxmox VE :
{
{
use strict;
use strict;
}
}
}
}
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
signal-event console-save
dehydrated -c
dehydrated -c
===Obtaining certificates for a private SME Server===
Ces certificats seront automatiquement renouvelés, tout comme le certificat du serveur principal.
*The hostname of your internal SME Server (example: internal.mydomain.tld) resolves, on the public Internet, to a valid IP address
*The host to which internal.mydomain.tld resolves (example: external.mydomain.tld) has a running web server on port 80
=== Obtenir des certificats pour un serveur KOOZALI SME privé ===
*The root user from internal.mydomain.tld can connect to external.mydomain.tld via SSH without entering a password (i.e., you've set up SSH public key authentication)
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 hookScript enabled
config setprop letsencrypt host '''external.mydomain.tld'''
config setprop letsencrypt host '''passerelle.mon-domaine.com'''
config setprop letsencrypt user '''root'''
config setprop letsencrypt user '''root'''
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''
config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''
signal-event console-save
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/.