Difference between revisions of "Letsencrypt/fr"

From SME Server
Jump to navigationJump to search
(6 intermediate revisions by the same user not shown)
Line 78: Line 78:
 
Cette contribution permettra d'obtenir un seul certificat de Let's Encrypt. Le certificat inclura tous les domaines et noms d'hôtes qui :
 
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 sur votre serveur KOOZALI SME (par exemple via le gestionnaire du serveur), et
    sont configurés pour utiliser Let's Encrypt.
+
* 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 :
 
Par exemple, votre serveur KOOZALI SME peut contenir les domaines et les noms d'hôtes suivants :
Line 103: Line 103:
 
  db hosts setprop www.domaine1.com letsencryptSSLcert enabled
 
  db hosts setprop www.domaine1.com letsencryptSSLcert enabled
  
Vous pouvez obtenir un certificat pour l'un des éléments suivants: tous les domaines, tous les noms d'hôte ou tous les domaines ET les noms d'hôtes. Définissez uniquement l'un des éléments suivants.
+
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 domains
  
Line 114: Line 119:
 
  config setprop letsencrypt configure none
 
  config setprop letsencrypt configure none
  
Avec la configuration du système décrite ci-dessus, la définition de «domaines» 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 [[Letsencrypt # Some_challenges_complete_successfully_but_some_hostnames_fail | NOTE]] avant de régler ceci sur « all ».' ''
+
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 [[Letsencrypt # Some_challenges_complete_successfully_but_some_hostnames_fail | NOTE]] avant de régler ceci sur « all ».' ''
  
 
====Autres paramètres de configuration ====
 
====Autres paramètres de configuration ====
Line 141: Line 149:
 
  dehydrated -c
 
  dehydrated -c
  
Si il s'imprime uniquement "# INFO: Using main config file /etc/dehydrated/config"" et vous renvoie à l'invite du shell, voir [[Bugzilla:10300]].
+
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.
 
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.
Line 154: Line 162:
 
  dehydrated -c -x
 
  dehydrated -c -x
  
L'indicateur -x ici est nécessaire pour forcer la déshydratation à obtenir un nouveau certificat, même si vous avez un certificat existant qui est valide pendant plus de 30 jours.
+
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é.
 
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é.
Line 178: Line 186:
 
  dehydrated -c -x
 
  dehydrated -c -x
  
==Installation manuellle de « Dehydrated »==
+
==Installation manuelle de « Dehydrated »==
{{warning box| type=Attention :| les éléments suivants ne doivent pas être exécutés si vous avez installé le paquet de la contribution smeserver-letsencrypt car cela a déjà été géré par la contribution.}}
+
{{warning box| type=Attention :| les éléments suivants ne doivent pas être exécutés si vous avez installé le paquet de la contribution smeserver-letsencrypt car cela est déjà géré par la contribution.}}
As discussed above, dehydrated is a lightweight ACME client that's implemented as a BASH script. It has very few dependencies, and is a better fit for the "SME way" of doing things than the official certbot client. If you'd prefer to configure it manually, rather than installing the contrib described above, you may do so manually or by pulling a copy of the latest version using git.
+
Comme exposé ci-dessus, «dehydrated» est un client ACME léger qui est implémenté en tant que script BASH. Il a très peu de dépendances, et il est mieux adapté pour la «façon de faire de KOOZALI» que le client officiel de certbot. Si vous préférez le configurer manuellement, plutôt que d'installer la contribution décrite ci-dessus, vous pouvez le faire manuellement ou à partir d'une copie de la dernière version en utilisant git.
  
===Install of Dehydrated rpm from smecontrib repository===
+
=== Installation du paquet «dehydrated» à partir du dépôt smecontrib ===
The dehydrated script has been imported into the contribs repository and can be installed as follows:
+
Le script déshydraté a été importé dans le dépôt contribs et peut être installé comme suit :
  
 
  yum --enablerepo=smecontribs install dehydrated
 
  yum --enablerepo=smecontribs install dehydrated
  
The script must be configured as described below.
+
Le script doit être configuré comme décrit ci-dessous.
  
===Git install of latest version===
+
===Installation de la dernière version de git===
  
If you need or want the absolute latest version of the script then you can manually install as follows:
+
Si vous avez besoin ou si vous voulez la toute dernière version du script, vous pouvez l'installer manuellement comme suit :
  
Begin by installing git:
+
Commencez en installant git :
 
  yum install git
 
  yum install git
  
Then download the Dehydrated client:
+
Téléchargez ensuite le client «Dehydrated» :
 
  cd /etc
 
  cd /etc
 
  git clone https://github.com/lukas2511/dehydrated
 
  git clone https://github.com/lukas2511/dehydrated
 
  mv dehydrated/dehydrated /usr/local/bin/
 
  mv dehydrated/dehydrated /usr/local/bin/
  
===Manual Configuration of Dehydrated===
+
===Configuration manuelle de «Dehydrated»===
  
You'll need to create two configuration files for Dehydrated.
+
Vous devrez créer deux fichiers de configuration pour «Dehydrated».
 
  cd /etc/dehydrated
 
  cd /etc/dehydrated
 
  mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
  mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
  nano -w domains.txt
 
  nano -w domains.txt
  
In this file, you'll list every hostname that you want your certificate to cover, all on one line. It will look like this:
+
Dans ce fichier, vous ajouterez chaque nom d'hôte que vous voulez que votre certificat couvre, tous sur une seule ligne. Cela ressemblera à ceci :
 
  domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org
 
  domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org
Ctrl-X to exit, Y to save.
+
Ctrl-X pour quitter, Y pour sauvegarder.
  
Second, you'll need to create the configuration file '''config''':
+
En second, vous devrez créer le fichier de configuration '''config''' :
 
  nano -w config
 
  nano -w config
  
It should look like this:
+
Cela devrait ressembler à :
 
  #!/bin/bash
 
  #!/bin/bash
 
  # config
 
  # config
Line 224: Line 232:
 
  CONTACT_EMAIL="admin@yourdomain.com"
 
  CONTACT_EMAIL="admin@yourdomain.com"
  
Ctrl-X to exit, Y to save.
+
Ctrl-X pour quitter, Y pour sauvegarder.
  
For testing purposes, it's recommended that you uncomment the third line (so it begins with "CA=").  Any certificates issued while testing will not be trusted, but they will also not count against your rate limits. Once your configuration is set, you can comment out that line and re-run dehydrated.
+
Pour les phases de test, il est recommandé de dé-commenter la troisième ligne (celle qui commence par «CA="...»).  Durant les tests, aucunes demandes de certificats ne seront effectuées, mais cela n'affectera pas non plus votre nombre limite. Une fois que votre configuration sera réglée, vous pourrez dé-commenter cette ligne et relancer «dehydrated».
 +
 
 +
Vous devrez créer un script «hook» personnalisé pour configurer correctement la base de données de configuration et déclencher le rechargement de vos services système lors de l'émission ou du renouvellement d'un certificat.
  
You'll need to create a custom "hook" script to set the config database up properly, and to trigger reloads of your system services when a certificate is issued or renewed.
 
 
  nano /usr/local/bin/dehydrated-hook
 
  nano /usr/local/bin/dehydrated-hook
  
Its contents should look like this:
+
Son contenu devrait ressembler à :
 
  #!/bin/bash
 
  #!/bin/bash
 
   
 
   
Line 244: Line 253:
 
  fi
 
  fi
  
Ctrl-X to exit, Y to save. Then make it executable:
+
Ctrl-X pour quitter, Y pour sauvegarder. Ensuite, rendez-le exécutable :
 
  chmod +x /usr/local/bin/dehydrated-hook
 
  chmod +x /usr/local/bin/dehydrated-hook
  
You'll also need to create a custom template fragment for Apache:
+
Vous devrez aussi créer un fragment personnalisé de modèle pour Apache :
 
  mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
 
  mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
 
  nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME
 
  nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME
  
The contents of that file should look like:
+
Les contenus de ce fichier devrait ressembler à :
 
  # Alias for letsencrypt
 
  # Alias for letsencrypt
 
  Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
  Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
Again, Ctrl-X to exit, Y to save.
+
A nouveau, Ctrl-X pour quitter, Y pour sauvegarder.
  
Expand the template and restart apache:
+
Développez le modèle et redémarrez Apache :
 
  expand-template /etc/httpd/conf/httpd.conf
 
  expand-template /etc/httpd/conf/httpd.conf
 
  service httpd-e-smith restart
 
  service httpd-e-smith restart
  
Now you're ready to run dehydrated and get your certificate.
+
Maintenant, vous êtes prêt(e) à lancer «dehydrated» et à obtenir votre certificat.
 
  dehydrated -c
 
  dehydrated -c
  
The script will run for a moment and should report success. If it does, look in /etc/dehydrated/certs/YOURDOMAIN and see if you have your files there. You should see a number of .pem files, at least one .csr file, and five symbolic links (chain.pem, cert.csr, cert.pem, fullchain.pem, and privkey.pem). If you do, congratulations! You've successfully obtained your certificate. The hook script should have also configured your server to use the new certificate. To make sure, run
+
Le script s'exécutera pendant un moment et devrait indiquer le succès. Si c'est le cas, regardez dans /etc/dehydrated/certs/VOTRE_DOMAINE et voyez si vous y avez vos fichiers. Vous devriez voir un certain nombre de fichiers .pem, au moins un fichier .csr, et cinq liens symboliques (chain.pem, cert.csr, cert.pem, fullchain.pem et privkey.pem). Si c'est le cas, félicitations ! Vous avez réussi à obtenir votre certificat. Le script «hook» doit également avoir configuré votre serveur pour utiliser le nouveau certificat. Pour être sûr, exécutez :
 
  config show modSSL
 
  config show modSSL
and make sure there are values set for crt, key, and CertificateChainFile.
+
et assurez-vous qu'il y a des valeurs définies pour crt, key, et CertificateChainFile.
  
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run
+
Si «dehydrated» fonctionne avec succès en mode test mode, re-commentez la troisième ligne «CA=...» dans /etc/dehydrated/config et exécutez
 
  dehydrated -c -x
 
  dehydrated -c -x
  
to obtain trusted a trusted certificate.
+
pour obtenir en confiance un certificat de confiance.
 +
 
 +
===Renouvellement===
 +
Une fois exécuté, le script «dehydrated» vérifiera votre certificat existant pour voir combien de temps il est valide. Si sa durée de vie est inférieure à 30 jours (par défaut, cela peut être modifié en réglant RENEW_DAYS dans config sur autre chose que 30), le script renouvellera vos certificats. S'il reste plus de 30 jours, le script se terminera sans autre action. Tout ce qui est nécessaire est d'exécuter quotidiennement «dehydrated» :
  
===Renewal===
 
When run, the dehydrated script will check your existing certificate to see how long it's valid.  If it has less than 30 days' lifetime remaining (by default; this can be changed by setting RENEW_DAYS in config to something other than 30), the script will renew your certificates.  If more than 30 days remain, the script will exit without further action.  All that's necessary is to run dehydrated daily:
 
 
  nano -w /etc/cron.daily/call-dehydrated
 
  nano -w /etc/cron.daily/call-dehydrated
  
Enter the following in this file:
+
Entrez ce qui suit dans ce fichier :
 
  #!/bin/bash
 
  #!/bin/bash
 
  /usr/bin/dehydrated -c
 
  /usr/bin/dehydrated -c
Ctrl-X to exit, Y to save. Then make it executable:
+
Ctrl-X pour quitter, Y pour sauvegarder. Ensuite, rendez-le exécutable :
 
  chmod +x /etc/cron.daily/call-dehydrated
 
  chmod +x /etc/cron.daily/call-dehydrated
  
{{warning box| end of the manual installation and configuration of dehydrated without smeserver-letsencrypt contrib}}
+
{{warning box| type=Attention :| fin de l'installation et de la configuration manuelles de «dehydrated» sans la contribution smeserver-letsencrypt.}}
  
 
==Imposer le SSL ==
 
==Imposer le SSL ==

Revision as of 13:52, 15 July 2018


PythonIcon.png Skill level: Medium
The instructions on this page require a basic knowledge of linux.


Introduction

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.

Version

Add-on 10:
Contrib 9:
smeserver-letsencrypt
The latest version of smeserver-letsencrypt is available in the SME repository, click on the version number(s) for more information.



Update 10:
Contrib 9:
dehydrated
The latest version of dehydrated is available in the SME repository, click on the version number(s) for more information.



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 --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 --enablerepo=smecontribs

Il est important d'effectuer l'usuel :

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

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.

Exemples de démarrage rapide

Pour le test ( 'ajuster les domaines et les hôtes' ) :

 config setprop letsencrypt ACCEPT_TERMS yes status test
 #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

Installation manuelle de « Dehydrated »

Warning.png Attention :
les éléments suivants ne doivent pas être exécutés si vous avez installé le paquet de la contribution smeserver-letsencrypt car cela est déjà géré par la contribution.


Comme exposé ci-dessus, «dehydrated» est un client ACME léger qui est implémenté en tant que script BASH. Il a très peu de dépendances, et il est mieux adapté pour la «façon de faire de KOOZALI» que le client officiel de certbot. Si vous préférez le configurer manuellement, plutôt que d'installer la contribution décrite ci-dessus, vous pouvez le faire manuellement ou à partir d'une copie de la dernière version en utilisant git.

Installation du paquet «dehydrated» à partir du dépôt smecontrib

Le script déshydraté a été importé dans le dépôt contribs et peut être installé comme suit :

yum --enablerepo=smecontribs install dehydrated

Le script doit être configuré comme décrit ci-dessous.

Installation de la dernière version de git

Si vous avez besoin ou si vous voulez la toute dernière version du script, vous pouvez l'installer manuellement comme suit :

Commencez en installant git :

yum install git

Téléchargez ensuite le client «Dehydrated» :

cd /etc
git clone https://github.com/lukas2511/dehydrated
mv dehydrated/dehydrated /usr/local/bin/

Configuration manuelle de «Dehydrated»

Vous devrez créer deux fichiers de configuration pour «Dehydrated».

cd /etc/dehydrated
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
nano -w domains.txt

Dans ce fichier, vous ajouterez chaque nom d'hôte que vous voulez que votre certificat couvre, tous sur une seule ligne. Cela ressemblera à ceci :

domain1.com www.domain1.com mail.domain1.com domain2.net www.domain2.net domain3.org ftp.domain3.org

Ctrl-X pour quitter, Y pour sauvegarder.

En second, vous devrez créer le fichier de configuration config :

nano -w config

Cela devrait ressembler à :

#!/bin/bash
# config
# CA="https://acme-staging.api.letsencrypt.org/directory"
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
HOOK="/usr/local/bin/dehydrated-hook"
# E-mail to use during the registration (default: <unset>)
CONTACT_EMAIL="admin@yourdomain.com"

Ctrl-X pour quitter, Y pour sauvegarder.

Pour les phases de test, il est recommandé de dé-commenter la troisième ligne (celle qui commence par «CA="...»). Durant les tests, aucunes demandes de certificats ne seront effectuées, mais cela n'affectera pas non plus votre nombre limite. Une fois que votre configuration sera réglée, vous pourrez dé-commenter cette ligne et relancer «dehydrated».

Vous devrez créer un script «hook» personnalisé pour configurer correctement la base de données de configuration et déclencher le rechargement de vos services système lors de l'émission ou du renouvellement d'un certificat.

nano /usr/local/bin/dehydrated-hook

Son contenu devrait ressembler à :

#!/bin/bash

if [ $1 = "deploy_cert" ]; then
  KEY=$3
  CERT=$4
  CHAIN=$6
  /sbin/e-smith/db configuration setprop modSSL key $KEY
  /sbin/e-smith/db configuration setprop modSSL crt $CERT
  /sbin/e-smith/db configuration setprop modSSL CertificateChainFile $CHAIN
  /sbin/e-smith/signal-event ssl-update
fi

Ctrl-X pour quitter, Y pour sauvegarder. Ensuite, rendez-le exécutable :

chmod +x /usr/local/bin/dehydrated-hook

Vous devrez aussi créer un fragment personnalisé de modèle pour Apache :

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
nano -w /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts40ACME

Les contenus de ce fichier devrait ressembler à :

# Alias for letsencrypt
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge

A nouveau, Ctrl-X pour quitter, Y pour sauvegarder.

Développez le modèle et redémarrez Apache :

expand-template /etc/httpd/conf/httpd.conf
service httpd-e-smith restart

Maintenant, vous êtes prêt(e) à lancer «dehydrated» et à obtenir votre certificat.

dehydrated -c

Le script s'exécutera pendant un moment et devrait indiquer le succès. Si c'est le cas, regardez dans /etc/dehydrated/certs/VOTRE_DOMAINE et voyez si vous y avez vos fichiers. Vous devriez voir un certain nombre de fichiers .pem, au moins un fichier .csr, et cinq liens symboliques (chain.pem, cert.csr, cert.pem, fullchain.pem et privkey.pem). Si c'est le cas, félicitations ! Vous avez réussi à obtenir votre certificat. Le script «hook» doit également avoir configuré votre serveur pour utiliser le nouveau certificat. Pour être sûr, exécutez :

config show modSSL

et assurez-vous qu'il y a des valeurs définies pour crt, key, et CertificateChainFile.

Si «dehydrated» fonctionne avec succès en mode test mode, re-commentez la troisième ligne «CA=...» dans /etc/dehydrated/config et exécutez

dehydrated -c -x

pour obtenir en confiance un certificat de confiance.

Renouvellement

Une fois exécuté, le script «dehydrated» vérifiera votre certificat existant pour voir combien de temps il est valide. Si sa durée de vie est inférieure à 30 jours (par défaut, cela peut être modifié en réglant RENEW_DAYS dans config sur autre chose que 30), le script renouvellera vos certificats. S'il reste plus de 30 jours, le script se terminera sans autre action. Tout ce qui est nécessaire est d'exécuter quotidiennement «dehydrated» :

nano -w /etc/cron.daily/call-dehydrated

Entrez ce qui suit dans ce fichier :

#!/bin/bash
/usr/bin/dehydrated -c
Ctrl-X pour quitter, Y pour sauvegarder. Ensuite, rendez-le exécutable :
chmod +x /etc/cron.daily/call-dehydrated


Warning.png Attention :
fin de l'installation et de la configuration manuelles de «dehydrated» sans la contribution smeserver-letsencrypt.


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. 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

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

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.

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

mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname

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.

mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/
nano -w 05deploy_cert_hostname

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:

{
    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

    }
}

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:

{
    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

    }
}

The following fragment would install the new certificate on a Proxmox VE host:

{
    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

    }
}

Once you've created the template fragments, expand the templates and run dehydrated to generate the certificates:

signal-event console-save
dehydrated -c

These certificates will be automatically renewed, just like the main server certificate.

Obtaining certificates for a private SME Server

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:

  • 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
  • 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)

This method uses a simple script that's included in the smeserver-letsencrypt contrib, which requires that four database entries be set:

config setprop letsencrypt hookScript enabled
config setprop letsencrypt host external.mydomain.tld
config setprop letsencrypt user root
config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
signal-event console-save

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/

Bugs

Please raise bugs under the SME-Contribs section in bugzilla and select the smeserver-letsencrypt component or use this link


IDProductVersionStatusSummary (11 tasks)
12325SME Contribs10.0CONFIRMEDrenewal fails after domain deleted from manager.
11796SME ContribsFuturCONFIRMEDIs the dns-01 Challenge Supported or is it in planing?
11442SME Contribs10alphaCONFIRMEDmultiple fragments related to some other bugs
10920SME Contribs10alphaCONFIRMEDmove .well-known/acme-challenge out of the Primary ibay
10836SME Contribs9.2CONFIRMEDforce migration from acme-v1 to acme-v2
10818SME Contribs9.2CONFIRMEDtemplate does not respect domain-deleted
10656SME Contribs9.2CONFIRMEDNo letsencrypt certificate for Internet enable password protected Ibay
10483SME Contribs9.2CONFIRMEDrenewal fails with ibay using password
10462SME ContribsFuturCONFIRMEDNFR: implement per certificate / domain
10280SME Contribs9.2CONFIRMEDadd test for domain and host to disable the one at least defined in publicly available dns
9196SME Contribs10.0CONFIRMEDServer manager panel for the letsencrypt

Changelog

Only released version in smecontrib are listed here.

smeserver-letsencrypt Changelog: SME 10 (smeaddons)
2022/07/30 Brian Read 0.5-24.sme
- Re-build and link to latest devtools [SME: 11997]
2022/07/25 Jean-Philippe Pialasse 0.5-23.sme
- add to core backup [SME: 12011]
2022/06/15 Brian Read 0.5-22.sme
- Add action to check if dehydrated.timer is running and stop it if so [SME: 11996]
2022/06/12 Brian Read 0.5-21.sme
- Stop systemd timer runnning as well as cron [SME: 11990]
2022/03/23 Jean-Philippe Pialasse 0.5-19.sme
- use a general Alias for acme path and a proxypass [SME: 10637]