Letsencrypt/fr
 | |
| letsencrypt logo | |
| Maintainer | John Crisp |
|---|---|
| Url | https://github.com/dehydrated-io/dehydrated |
| Licence | MIT license |
| Category | |
| Tags | dehydrated, letsencrypt, dns, http, ssl |
Mainteneur
John Crisp
Version
Description
Let’s Encrypt est une nouvelle Autorité de Certification (CA) : c'est gratuit, automatique et libre. Son but principal est de permettre aux gens de crypter leur trafic gratuitement, facilement et automatiquement. Les certificats délivrés doivent être renouvelés tous les 3 mois.
En décembre 2015, le service Letsencrypt était dans un stade bêta public. Let's Encrypt (LE) émet des certificats de confiance valides, mais le code du client (et, dans une moindre mesure, le code du serveur) est susceptible d'être dans un état fluctuant. Au cours des étapes initiales du bêta public, LE met en œuvre une limitation de débit, en n'autorisant pas plus de cinq certificats par domaine sur une période de sept jours consécutifs. Cela peut les rendre impropres aux utilisateurs de services DNS dynamiques. Les dernières informations sur la limitation des quantités sont publiées sur cette page de la documentation letsencrypt.org. Au 26 mars 2016, le nombre limite a été augmenté à 20 certificats par domaine par semaine.
Si vous allez faire des tests qui nécessiteraient de demander beaucoup de certificats dans un court laps de temps, nous vous encourageons à utiliser l'autorité de certification intermédiaire (staging CA) Letsencrypt à cette fin. Les certificats générés par cette CA ne seront pas approuvés par votre navigateur et sembleront être émis par « Fake LE Intermédiate X1 », mais il vous permettra de valider l'ensemble des outils et flux de travail.
L'état actuel des services Letsencrypt peut être trouvé sur leur page.
Plusieurs clients sont disponibles pour les services Letsencrypt. Le client « certbot » officiel de letsencrypt.org est assez complet mais possède un certain nombre de dépendances qu'il est nécessaire d'installer. Il nécessite aussi une version plus récente de Python que celle fournie avec une installation de serveur KOOZALI SME standard. En raison de cette complexité et du manque de compatibilité avec SME 8.X, ce document décrit l'installation et l'utilisation de dehydrated, un client alternatif mis en œuvre en tant que script shell BASH.
Prérequis
Le client et le serveur Letsencrypt interagissent pour confirmer que la personne demandant un certificat pour un nom d'hôte contrôle réellement cet hôte. Pour cette raison, il y a quelques prérequis pour votre configuration. Par exemple, si vous essayez d'obtenir un certificat pour www.exemple.com, les conditions suivantes doivent être remplies :
- www.exemple.com est un nom de domaine valide - le domaine a été enregistré et les enregistrements DNS sont publiés en ce sens ;
- la résolution de www.exemple.com aboutit à votre serveur SME - les enregistrements DNS publiés donnent l'adresse IP externe de votre serveur SME interrogé pour www.exemple.com ;
- votre serveur SME est connecté à Internet et est capable d'établir des connexions sortantes sur les ports 80 et 443 ;
- le port 80 de votre serveur SME est ouvert sur Internet (c'est-à-dire qu'Internet peut atteindre votre serveur sur le port 80) - vous n'êtes pas derrière un pare-feu ou un filtrage du FAI qui le bloquerait. Si vous avez rendu SSL obligatoire pour la baie d'information « Primary », le port 443 doit être ouvert.
Letsencrypt souhaite que les certificats d'émission incluent plusieurs noms d'hôte (par exemple, www.exemple.com, exemple.com et mail.exemple.com), qui feraient tous partie de la demande. Tout ce qui précède doit être vrai pour tous les noms d'hôte que vous souhaitez inclure dans le certificat.
Assurez-vous que vous avez toute cette configuration en place avant.
Préparation
Avant de commencer l'installation, effectuez une vérification pour voir si vous ou une contribution installée, auraient configuré des valeurs personnalisées sur votre certificat TLS/SSL :
# config show modSSL
Par défaut, cela devrait afficher :
modSSL=service
TCPPort=443
access=public
status=enabled
Si cela affiche des valeurs pour crt, key ou CertificateChainFile, notez-les. Si vous rencontrez un problème avec les fichiers du certificat généré par Letsencrypt, vous pourrez revenir à vos modifications. Pour effectuer une «sauvegarde» de votre clé et de vos propriétés existantes, vous pouvez émettre :
config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"
Installation de la contribution de Dehydrated
John Crisp a préparé le fichier pour le script de Dehydrated, en créant les fichiers de configuration appropriés et en l'intégrant au système de modèles SME. C'est la manière la plus simple d'installer Dehydrated sur votre serveur KOOZALI SME.
Installation
yum install smeserver-letsencrypt
Si vos dépôts « smeaddons » sont désactivés, ajoutez « --enablerepo=smecontribs ».
Vous devez ensuite configurer les domaines et les hôtes pour lesquels vous souhaitez demander un certificat. Voir plus bas, la section « Configuration ».
Mises à jour
Votre serveur disposera de mises à jour disponibles dans le dépôt smecontribs. Si vous avez déjà installé smeserver-letsencrypt à partir du dépôt « reetp », vous devez vous assurer que vous avez défini la propriété de configuration de « ACCEPT_TERMS » :
config setprop letsencrypt ACCEPT_TERMS yes signal-event console-save
Ré-actualisation
Quelques problèmes signalés lors de la mise à niveau des contributions, voir Bugzilla:10286 and Bugzilla:10097
Une mise à jour complète peut être effectuée comme suit :
yum update smeserver-letsencrypt dehydrated
Si vos dépôts « smeaddons » sont désactivés, ajoutez « --enablerepo=smecontribs ».
Il est important d'effectuer la commande habituelle :
signal-event post-upgrade; signal-event reboot
à défaut :
signal-event console-save
Ne pas le faire pourrait laisser la contribution hors service et vos certificats ne seraient pas renouvelés.
Configuration
Il y a plusieurs configurations d'entrées de la base de données qui doivent être faites afin de mettre en place cette contribution. La plupart d'entre elles indiquent aux scripts quels noms d'hôte doivent faire partie de votre certificat.
Hôtes et domaines du certificat
Cette contribution permettra d'obtenir un seul certificat de Let's Encrypt. Le certificat inclura tous les domaines et noms d'hôtes qui :
- sont configurés sur votre serveur KOOZALI SME (par exemple via le gestionnaire du serveur), et
- sont configurés pour utiliser Let's Encrypt.
Par exemple, votre serveur KOOZALI SME peut contenir les domaines et les noms d'hôtes suivants :
- domaine1.com
- www.domaine1.com
- mail.domaine1.com
- ftp.domaine1.com
- domaine2.com
- www.domaine2.com
- mail.domaine2.com
Pour chaque DOMAINE que vous voulez voir inclus dans le certificat, exécutez cette commande :
db domains setprop $DOMAINE letsencryptSSLcert enabled
En utilisant l'exemple ci-dessus, une invocation de la commande ressemblerait à ceci :
db domains setprop domaine1.com letsencryptSSLcert enabled
Pour chaque NOM_D_HOTE que vous voulez voir inclus dans le certificat, exécutez cette commande :
db hosts setprop $NOM_D_HOTE letsencryptSSLcert enabled
En utilisant l'exemple ci-dessus, une invocation de la commande ressemblerait à ceci :
db hosts setprop www.domaine1.com letsencryptSSLcert enabled
Vous pouvez obtenir un certificat pour l'un des ensembles suivants :
- tous les domaines,
- tous les noms d'hôtes ou
- tous les domaines ET les noms d'hôtes.
Définissez uniquement l'un des ensembles suivants.
config setprop letsencrypt configure domains
config setprop letsencrypt configure hosts
config setprop letsencrypt configure all
Pour utiliser des hôtes ou des domaines activés individuellement, laissez le paramètre par défaut « none ».
config setprop letsencrypt configure none
Avec la configuration du système décrite ci-dessus :
- la définition de « domains » obtiendra un certificat couvrant domain1.com et domain2.com, mais pas www.domain1.com, etc. ;
- le réglage sur « hosts » obtiendra un certificat couvrant www.domain1 .com, mail.domain1.com, ftp.domain1.com, etc., mais pas domain1.com ou domain2.com ;
- le réglage de cette propriété sur « all » inclura tous les noms de domaine et les noms d'hôtes dans le certificat. 'voyez NOTE avant de régler ceci sur « all ».'
Autres paramètres de configuration
Aucun autre paramètre n'est obligatoire. Cependant, il est recommandé de configurer une adresse courriel. S'il y a un problème avec le renouvellement de votre certificat, et qu'il arrive à expiration, les serveurs de Let's Encrypt vous en informeront. Faites-le avec cette commande :
config setprop letsencrypt email admin@domaine1.com
Le domaine de messagerie spécifié ici n'a pas besoin de correspondre à l'un des domaines pour lesquels vous allez demander un certificat.
Vous pouvez également définir la longueur de la clé privée de votre certificat, si vous ne voulez pas la valeur par défaut de 4096 bits. Cela ne devrait pas être nécessaire dans la plupart des cas, mais si vous le souhaitez, utilisez cette commande pour le faire :
config setprop letsencrypt keysize NOMBRE
Accepter les conditions de Let's Encrypt
Lisez d'abord, s.v.p., les termes des conditions d'utilisation de Let's Encrypt [[1]] puis exécutez :
config setprop letsencrypt ACCEPT_TERMS yes
V2 API
Avec la dernière version de letsencrypt / deshydrated, l'API V2 est nécessaire pour créer de nouveaux certificats. La version 1 est déconseillée pour la création de nouveaux certificats, mais elle reste valable pour les certificats existants créés avec elle.
La clé s'appelle API. La valeur par défaut est « 1 » si elle n'est pas définie. Les options sont « 1 », « 2 », « auto ».
Pour mettre à jour les certificats V1 actuels, laissez la valeur par défaut ou définissez-la sur « 1 », « auto ».
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes configure=none email=####@#####.### hookScript=disabled status=enabled
# config setprop letsencrypt API 1 # signal-event console-save
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes API=1 configure=none email=####@#####.### hookScript=disabled status=enabled
Pour créer un nouveau certificat ou mettre à jour une configuration V2 à 2 :
# config setprop letsencrypt API 2 # signal-event console-save
# config show letsencrypt letsencrypt=service ACCEPT_TERMS=yes API=2 configure=none email=####@#####.### hookScript=disabled status=enabled
Activer le mode test
L'étape suivante consiste à activer le mode test. Cela va obtenir des certificats du serveur d'étape. Les limites de quantité présentées dans l'introduction ne s'appliqueront pas, donc toute erreur ou autre problème ne vous empêchera pas d'obtenir votre certificat de production. Activer le mode test en utilisant cette commande :
config setprop letsencrypt status test signal-event console-save
Vous pouvez maintenant exécuter « dehydrated » pour la première fois et vous assurer qu'il est capable de se connecter aux serveurs de Let's Encrypt, de valider les noms d'hôtes que vous demandez et d'émettre des certificats. Pour ce faire, exécutez :
dehydrated -c
S'il s'imprime uniquement "# INFO: Using main config file /etc/dehydrated/config"" et vous renvoie à l'invite du shell, voir Bugzilla:10300.
Si cela fonctionne sans erreur, essayez de vous connecter à la page du gestionnaire de votre serveur. Vous devriez voir une erreur indiquant que le certificat de sécurité n'a pas été émis par une autorité de certification approuvée. C'est parfaitement normal. Cependant, il devrait y avoir un certificat, il devrait inclure tous les noms d'hôte que vous vouliez inclure, et il devrait être valide pour les quatre-vingt-dix prochains jours. Si cela a réussi, passez à la production.
Activer le mode production
Une fois que vous avez testé avec succès votre installation, réglez-la en mode production en utilisant les commandes suivantes :
config setprop letsencrypt status enabled signal-event console-save
Procurez-vous ensuite un nouveau certificat à partir du serveur de production Let's Encrypt :
dehydrated -c -x
L'indicateur -x ici est nécessaire pour forcer «dehydrated» à obtenir un nouveau certificat, même si vous avez un certificat existant qui est valide pendant plus de 30 jours.
Si cette commande a réussi, félicitations ! Vous avez réussi à obtenir un certificat TLS de confiance et valide, qui se renouvellera automatiquement à perpétuité.
Une fois que vous avez obtenu votre certificat et configuré votre serveur, testez votre serveur avec un outil comme SSLLabs.com pour vous assurer qu'il fonctionne correctement.
Archiver les vieux certificats
Une nouvelle fonction vous permet de nettoyer les vieux certificats et de les archiver.
dehydrated --cleanup (-gc)
Exemples de démarrage rapide
Pour le test ( 'ajuster les domaines et les hôtes' ) :
config setprop letsencrypt ACCEPT_TERMS yes status test API 2 #pour chacun de vos domaines où vous voulez SSL, faire ce qui suit : db domains setprop domaine1.com letsencryptSSLcert enabled #pour chacun de vos hôtes (sous-domaines) où vous voulez SSL, faire ce qui suit : db hosts setprop www.domaine1.com letsencryptSSLcert enabled signal-event console-save dehydrated -c
Vérifiez que les certificats sont disponibles (votre navigateur émettra toujours une erreur, mais vous pouvez explorer le contenu du certificat pour voir que l'autorité de certification de test Let's Encrypt a été utilisée pour signer votre certificat SSL et que tous vos domaines et hôtes sont dans le propriété « Certificate Subject Alt Name ».
Pour la production ( 'ajustez votre adresse courriel' ) :
config setprop letsencrypt status enabled email admin@domaine1.com signal-event console-save dehydrated -c -x
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.
Troubleshooting
Certificate Errors
Errors in the certificate files may prevent Apache and some other services from starting. If you previously had custom settings for modSSL, revert those with:
config setprop modSSL crt (old value) config setprop modSSL key (old value) config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)
If you did not have custom settings for modSSL, remove your changes with:
config delprop modSSL crt config delprop modSSL key config delprop modSSL CertificateChainFile
Once you've made these changes, do: signal-event post-upgrade
signal-event reboot
Also see
https://wiki.contribs.org/Useful_Commands#How_to_simply_recreate_the_certificate_for_SME_Server
rm /home/e-smith/ssl.{crt,key,pem}/*
config delprop modSSL CommonName
config delprop modSSL crt
config delprop modSSL key
signal-event post-upgrade
signal-event reboot
Authorization Errors
The first thing is to check all your domains can resolve
http://my.domain/.well-known/acme-challenge
Check that the following files are correctly generated
/etc/dehydrated/config /etc/dehydrated/domains.txt
Set letsencrypt back to test and remove any generated keys
db configuration setprop letsencrypt status test
rm /etc/dehydrated/certs/* -rf rm /etc/dehydrated/accounts/* -rf
Then run letsencrypt again
dehydrated -c
To restore the original certificates:
config delprop modSSL CertificateChainFile config delprop modSSL crt config delprop modSSL key
signal-event console-save
Errors
No registration exists matching provided key
If you see the following:
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}
https://github.com/lukas2511/letsencrypt.sh/issues/2
See above for removing private keys and regenerating
rateLimited, Too many currently pending Authorizations
If you see something like this you may have hit the rate limit:
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md
https://letsencrypt.org/docs/rate-limits/
Some challenges complete successfully but some hostnames fail
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate.
Using the command:
config setprop letsencrypt configure all
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and ONE does not resolve, the challenge will fail and the certificate will not generate at all.
To resolve this, issue the following command:
config setprop letsencrypt configure none
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:
db domains setprop domain1.com letsencryptSSLcert enabled
and for each hostname:
db hosts setprop www.domain1.com letsencryptSSLcert enabled
db hosts setprop mail.domain1.com letsencryptSSLcert enabled
until all the public facing hostnames are enabled followed by:
signal-event console-save
Thanks to MSmith for the following forum thread.
https://forums.contribs.org/index.php/topic,53052.0.html
Challenge fails with unauthorized 403 error
If your challenge returns something like the following:
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:unauthorized",
"detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text>
"status": 403
and your httpd error_log on your server shows something like this:
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied (13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied (13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied
You need to check the ownership and rights on /home/e-smith/files/ibays/Primary and on /home/e-smith/files/ibays/Primary/html. The contrib creates a hidden working directory at /home/e-smith/files/ibays/Primary/html/.well-known and inside that directory a second directory with the following path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with access denied
use the following to check the rights:
cd /home/e-smith/files/ibays
then
ls -l
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):
total 4 drwxr-xr-x 5 root root 4096 Jul 25 2016 Primary
If this is not what you see, you need to correct it.
THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT
From within /home/e-smith/files/ibays/ issue the following:
chown root:root Primary
If the rights are not correct, issue:
chmod 0755 Primary
Next check the html directory.
cd /home/e-smith/files/ibays/Primary
then
ls -l
on my test server I have the following
[root@backupserver Primary]# ls -l total 12 drwxr-s--- 2 admin shared 4096 Jul 25 2016 cgi-bin drwxr-s--- 2 admin shared 4096 Jul 25 2016 files drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html
If this is not what you see,
FIRST READ ABOVE WARNING
then adjust as follows
chown admin:shared html
If the rights are not correct, issue:
chmod 2750 html
rerun
dehydrated -c
and your challenges should complete.
https://forums.contribs.org/index.php/topic,53147.0.html
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/.
Bogues
Veuillez ouvrir des bogues dans la section SME-Contribs dans bugzilla et sélectionner le composant smeserver-letsencrypt ou utiliser ce lien.
| ID | Product | Version | Status | Summary (10 tasks) ⇒ |
|---|---|---|---|---|
| 12325 | SME Contribs | 10.0 | CONFIRMED | renewal fails after domain deleted from manager. |
| 11796 | SME Contribs | Futur | CONFIRMED | Is the dns-01 Challenge Supported or is it in planing? |
| 11442 | SME Contribs | 10alpha | CONFIRMED | multiple fragments related to some other bugs |
| 10920 | SME Contribs | 10alpha | CONFIRMED | move .well-known/acme-challenge out of the Primary ibay |
| 10836 | SME Contribs | 9.2 | CONFIRMED | force migration from acme-v1 to acme-v2 |
| 10818 | SME Contribs | 9.2 | CONFIRMED | template does not respect domain-deleted |
| 10656 | SME Contribs | 9.2 | CONFIRMED | No letsencrypt certificate for Internet enable password protected Ibay |
| 10483 | SME Contribs | 9.2 | CONFIRMED | renewal fails with ibay using password |
| 10462 | SME Contribs | Futur | CONFIRMED | NFR: implement per certificate / domain |
| 10280 | SME Contribs | 9.2 | CONFIRMED | add test for domain and host to disable the one at least defined in publicly available dns |
Changelog
Only released version in smecontrib are listed here.
- Re-build and link to latest devtools [SME: 11997]
- add to core backup [SME: 12011]
- Add action to check if dehydrated.timer is running and stop it if so [SME: 11996]
- Stop systemd timer runnning as well as cron [SME: 11990]
- use a general Alias for acme path and a proxypass [SME: 10637]
