Difference between revisions of "Letsencrypt/fr"

From SME Server
Jump to navigationJump to search
 
(77 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Languages|Letsencrypt}}
 
{{Languages|Letsencrypt}}
 
{{Level|Medium}}
 
{{Level|Medium}}
−
==Introduction==
+
<!-- here we define the contrib name variable -->
 +
<!-- we get the page title, remove suffix for translated version; if needed you can define there with the value you want-->
 +
{{#vardefine:contribname| {{lc: {{#titleparts:  {{BASEPAGENAME}} |1}} }} }}
 +
{{#vardefine:smecontribname| smeserver-{{lc: {{#titleparts:  {{BASEPAGENAME}} |1}} }} }}
 +
<!-- we define the language -->
 +
{{#vardefine:lang| {{lc:  {{#titleparts:    {{PAGENAME}} | | -1}}  }} |en }}
 +
{{Infobox contribs
 +
|name={{#var:contribname}}
 +
|image={{#var:contribname}}.jpg
 +
|description_image= {{#var:contribname}} logo
 +
|maintainer= John Crisp
 +
|licence= MIT license
 +
|url= https://github.com/dehydrated-io/dehydrated
 +
|category= certificates
 +
|tags=dehydrated,letsencrypt,dns,http,ssl
 +
}}
 +
==Mainteneur==
 +
John Crisp
 +
 
 +
== Version ==
 +
{{#set: Version=Contrib10}}
 +
{{#smeversion:smeserver-letsencrypt }}
 +
<br>
 +
 
 +
==Description==
 +
 
 +
{{warning box|type=Attention !| Le protocole original utilisé par Let’s Encrypt pour l’émission et la gestion des certificats est appelé ACMEv1. En mars 2018, Letsencrypt a introduit le support pour ACMEv2, une version plus récente du protocole qui correspond à ce qui a été finalisé aujourd'hui sous la RFC 8555 328. Ils encouragent les abonnés à passer au protocole ACMEv2.
 +
 
 +
En mars 2019, ils ont annoncé un plan de fin de vie pour ACMEv1.
 +
 
 +
En novembre 2019, ils ne permettront plus les nouvelles inscriptions de compte via leur point de terminaison API ACMEv1. '' 'IMPORTANT' '' Les comptes existants continueront à fonctionner normalement.
 +
 
 +
En juin 2020, ils ne permettront plus aux nouveaux domaines d'être validés via ACMEv1.
 +
 
 +
À compter du début de 2021, ils désactiveront occasionnellement l'émission et le renouvellement d'ACMEv1 pour des périodes de 24 heures, pas plus d'une fois par mois (le service OCSP ne sera pas affecté). Le but est d’induire des erreurs client susceptibles d’encourager les abonnés à se mettre à jour vers des clients ou des configurations utilisant ACMEv2.
 +
 
 +
Les échecs de renouvellement doivent être limités car les nouvelles validations de domaine seront déjà désactivées et nous recommandons de renouveler les certificats 30 jours avant leur expiration.
 +
 
 +
En juin 2021, ils désactiveront complètement ACMEv1 en tant que moyen viable d’obtenir un certificat Let’s Encrypt.}}
 +
 
 
[https://letsencrypt.org/ Let’s Encrypt] est une nouvelle Autorité de Certification (CA) :  
 
[https://letsencrypt.org/ 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.
 
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 de débit sont publiées sur [https://letsencrypt.org/docs/rate-limits/ cette page] de la documentation letsencrypt.org. Au 26 mars 2016, le nombre limite a été augmenté à 20 certificats par domaine par semaine.
+
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 [https://letsencrypt.org/docs/rate-limits/ 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.
 
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.
Line 12: Line 51:
  
 
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 ''[https://github.com/lukas2511/dehydrated dehydrated]'', un client alternatif mis en œuvre en tant que script shell BASH.
 
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 ''[https://github.com/lukas2511/dehydrated dehydrated]'', un client alternatif mis en œuvre en tant que script shell BASH.
−
 
−
=== Version ===
 
−
{{ #smeversion:smeserver-letsencrypt }}
 
−
<br>
 
−
{{ #smeversion:dehydrated }}
 
−
<br>
 
  
 
==Prérequis==
 
==Prérequis==
Line 32: Line 65:
  
 
==Préparation==
 
==Préparation==
−
Avant de commencer l'installation, vérifiez si vous ou une contribution installée avaient configuré toutes les valeurs personnalisées pour votre certificat TLS/SSL :
+
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
 
  # config show modSSL
Line 44: Line 77:
 
  config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"
 
  config show modSSL > "/root/db_configuration_modSSL_backup_$(date +%Y%m%d_%H%M%S)"
  
−
==Contrib Installation of Dehydrated==
+
==Installation de la contribution de Dehydrated letsencrypt==
−
John Crisp has prepared a contrib that installs the dehydrated script, creates the appropriate configuration files, and integrates with the SME templates system. This is the simplest way to install dehydrated on your SME Server.
+
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.
−
 
+
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
−
===Installation===
+
  yum install smeserver-letsencrypt
−
  yum install smeserver-letsencrypt --enablerepo=smecontribs
 
  
−
You will then need to configure the domains and hosts for which you want to ask a certificate. See the following Configuration section.
+
Vous aurez ensuite besoin de configurer les domaines et les hôtes pour lesquels vous voulez demander un certificat. Voir la section suivante « Configuration ».
  
−
===Updates===
+
Si votre dépôt « smeaddons » a été désactivé, ajoutez «  --enablerepo=smeaddons » et réactivez-le, comme il devrait l'être par défaut.
−
Your server will report available updates from the smecontribs repository as they are available. If you have previously installed smeserver-letsencrypt from the reetp repository, you will need to make sure that you've set the ACCEPT_TERMS configuration property:
+
db yum_repositories setprop smeaddons status enabled
 +
  signal-event yum-modify
  
−
config setprop letsencrypt ACCEPT_TERMS yes
+
</tab><tab name="Pour SME 9">
−
signal-event console-save
+
===Installation===
−
 
+
  yum install smeserver-letsencrypt
−
===Updating===
 
−
Few reported issue when upgrading the contribs  see [[Bugzilla:10286]] and [[Bugzilla:10097]]
 
−
 
 
−
A full update can be done as follow :
 
−
  yum update smeserver-letsencrypt dehydrated --enablerepo=smecontribs
 
−
 
 
−
It is important to do the usual
 
−
signal-event post-upgrade;  signal-event reboot
 
−
 
 
−
otherwise
 
 
  signal-event console-save
 
  signal-event console-save
  
−
failure to do this might leave the contribution not working and your certificates not renewed.
+
Vous aurez ensuite besoin de configurer les domaines et les hôtes pour lesquels vous voulez demander un certificat. Voir la section suivante « Configuration ».
−
 
+
Si votre dépôt « smeaddons » a été désactivé, ajoutez « --enablerepo=smeaddons » et réactivez-le, comme il devrait l'être par défaut.
−
===Configuration===
+
  db yum_repositories setprop smeaddons status enabled
−
There are several configuration database entries that need to be made in order to set up this contrib.  Most of them tell the scripts which hostnames need to be part of your certificate.
+
  signal-event yum-modify
−
 
 
−
====Hosts and domains for the certificate====
 
−
This contrib will obtain a single certificate from Let's Encrypt. The certificate will include all the domains and hostnames that:
 
−
* Are configured on your SME Server (e.g., through the Server Manager), and
 
−
* Are configured to use Let's Encrypt.
 
−
 
 
−
For example, your SME Server may contain the following domains and hostnames:
 
−
 
 
−
* domain1.com
 
−
: www.domain1.com
 
−
: mail.domain1.com
 
−
: ftp.domain1.com
 
−
* domain2.com
 
−
: www.domain2.com
 
−
: mail.domain2.com
 
−
 
 
−
For each DOMAIN that you want to be included in the certificate, run this command:
 
−
db domains setprop $DOMAIN letsencryptSSLcert enabled
 
−
 
 
−
Using the above example, one invocation of the command would look like this:
 
−
db domains setprop domain1.com  letsencryptSSLcert enabled
 
−
 
 
−
For each HOSTNAME that you want to be included in the certificate, run this command:
 
−
db hosts setprop $HOSTNAME letsencryptSSLcert enabled
 
−
 
 
−
Using the above example, one invocation of the command would look like this:
 
−
  db hosts setprop www.domain1.com letsencryptSSLcert enabled
 
−
 
 
−
You can obtain a certificate for either of the following: all domains, all hostnames, or all domains AND hostnames. Only set one of the following.
 
−
 
 
−
config setprop letsencrypt configure domains
 
−
 
 
−
  config setprop letsencrypt configure hosts
 
  
−
config setprop letsencrypt configure all
+
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 » :
  
−
To use individually enabled hosts or domains leave the default none.
 
  
−
config setprop letsencrypt configure none
 
  
 +
===Ré-actualisation===
 +
Quelques problèmes signalés lors de la mise à niveau des contributions, voir [[Bugzilla:10286]] and [[Bugzilla:10097]]
  
−
With the system configuration described above, setting this to "domains" will obtain a certificate covering domain1.com and domain2.com, but not www.domain1.com, etc.  Setting it to "hosts" will obtain a certificate covering www.domain1.com, mail.domain1.com, ftp.domain1.com, etc., but not domain1.com or domain2.com.  Setting this property to "all" will include all domain names and hostnames in the certificate. '''see [[Letsencrypt#Some_challenges_complete_successfully_but_some_hostnames_fail|NOTE]] before setting this to "all"'''
+
Une mise à jour complète peut être effectuée comme suit :
−
 
+
  yum update smeserver-letsencrypt dehydrated
−
====Other configuration properties====
 
−
No other settings are mandatory.  However, it's recommended to configure an email address.  If there should be a problem with renewing your certificate, and it comes close to expiring, the Let's Encrypt servers will notify you of this.  Do so with this command:
 
−
  config setprop letsencrypt email admin@domain1.com
 
−
 
 
−
The email domain specified here doesn't need to match any of the domains you're obtaining a cert for.
 
−
 
 
−
You can also set the length of your certificate's private key, if you don't want the default of 4096 bits.  This should not be necessary in most cases, but if desired, use this command to do so:
 
−
config setprop letsencrypt keysize NUMBER
 
−
 
 
−
===Accept Let's Encrypt terms ===
 
−
Please first read the condition terms for using Let's Encrypt [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]
 
 
  config setprop letsencrypt ACCEPT_TERMS yes
 
  config setprop letsencrypt ACCEPT_TERMS yes
−
 
−
===Enable Test Mode===
 
−
The next step is to enable test mode.  This will obtain certificates from the staging server.  The rate limits discussed in the introduction won't apply, so any errors or other issues won't prevent you from obtaining your production certificate.  Enable test mode using this command:
 
−
config setprop letsencrypt status test
 
−
signal-event console-save
 
−
 
−
You can now run dehydrated for the first time, and make sure it's able to connect to the Let's Encrypt servers, validate the hostnames you're requesting, and issue certificates.  To do this, run
 
−
dehydrated -c
 
−
 
−
If it prints only "# INFO: Using main config file /etc/dehydrated/config" and returns you to the shell prompt, see [[Bugzilla:10300]].
 
−
 
−
If this runs without errors, try to connect to your server-manager page.  You should see an error that the security certificate wasn't issued by a trusted certification authority; this is perfectly normal.  However, there should be a certificate, it should include all the hostnames you wanted included, and it should be valid for the next ninety days.  If this was successful, proceed to production.
 
−
 
−
===Enable Production Mode===
 
−
Once you've successfully tested your installation, set it to production mode using these commands:
 
−
 
−
config setprop letsencrypt status enabled
 
 
  signal-event console-save
 
  signal-event console-save
−
 
−
Then obtain a new certificate from the Let's Encrypt production server:
 
−
dehydrated -c -x
 
−
 
−
The -x flag here is needed to force dehydrated to obtain a new certificate, even though you have an existing certificate that's valid for more than 30 days.
 
  
−
If this command succeeded, congratulations!  You've successfully obtained a valid, trusted TLS certificate, which will automatically renew itself in perpetuity.  
+
Ne pas le faire pourrait laisser la contribution hors service et vos certificats ne seraient pas renouvelés.
 +
</tab>
 +
</tabs>
  
−
Once you've obtained your certificate and configured your server, test your server with a tool like [https://www.ssllabs.com/ssltest/ SSLLabs.com] to make sure it's working properly.
+
==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.
  
−
===Rush jobs===
+
===Exemples de démarrage rapide===
−
for the test ('''adjust the domains and hosts'''):
+
Pour le test ('''régler les domaines et les hôtes''') :
 +
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
 
  config setprop letsencrypt ACCEPT_TERMS yes status test
 
  config setprop letsencrypt ACCEPT_TERMS yes status test
−
  #foreach of your domains you want SSL do the following
+
  # tâche très rapide pour activer le domaine principal :
 +
db domains setprop $(config get DomainName) letsencryptSSLcert enabled
 +
#pour chacun de vos domaines pour lesquels vous voulez le SSL, faites :
 
  db domains setprop '''domain1.com''' letsencryptSSLcert enabled
 
  db domains setprop '''domain1.com''' letsencryptSSLcert enabled
−
  #foreach of your hosts (subdomains) you want SSL do the following
+
  #pour chacun de vos hôtes (sous-domaines) pour lesquels vous voulez le SSL, faites :
 +
db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled
 +
signal-event smeserver-letsencrypt-update
 +
dehydrated -c
 +
</tab><tab name="Pour SME 9">
 +
config setprop letsencrypt ACCEPT_TERMS yes status test API 2
 +
#pour chacun de vos domaines pour lesquels vous voulez le SSL, faites :
 +
db domains setprop '''domain1.com''' letsencryptSSLcert enabled
 +
#pour chacun de vos hôtes (sous-domaines) pour lesquels vous voulez le SSL, faites :
 
  db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled
 
  db hosts setprop '''www.domain1.com''' letsencryptSSLcert enabled
 
  signal-event console-save
 
  signal-event console-save
 
  dehydrated -c
 
  dehydrated -c
 +
</tab>
 +
</tabs>
 +
Vérifiez que les certificats sont valables (votre fureteur détectera encore une erreur mais vous pouvez explorer le contenu du certificat pour voir que l'Autorité de Certification (CA en anglais) a été utilisée pour signer votre certificat SSL et que tous vos domaines et hôtes sont dans la propriété « Autre nom de l'objet du certificat ».
  
−
Check that the certificates are available ( your browser will still issue an error, but you can explore the content of the certificate to see that the Let's Encrypt test CA was used to sign your SSL certificate and that all your domains and hosts are in the "Certificate Subject Alt Name" property.
+
Pour la production ('''régler votre adresse électronique'''):
−
 
+
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
−
for the production ('''adjust your email'''):
+
config setprop letsencrypt status enabled email admin@$(config get DomainName)
 +
signal-event smeserver-letsencrypt-update
 +
dehydrated -c -x
 +
</tab><tab name="Pour SME 9">
 
  config setprop letsencrypt status enabled email '''admin@domain1.com'''
 
  config setprop letsencrypt status enabled email '''admin@domain1.com'''
 
  signal-event console-save
 
  signal-event console-save
 
  dehydrated -c -x
 
  dehydrated -c -x
 +
</tab>
 +
</tabs>
  
−
==Manual Installation of Dehydrated==
+
===Configuration étape par étape===
−
{{warning box| the following is not to be executed if you have installed the smeserver-letsencrypt contrib rpm as it is already handled by the contrib}}
+
====Hôtes et domaines du certificat====
−
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.
+
Cette contribution permettra d'obtenir un seul certificat de Let's Encrypt. Le certificat inclura tous les domaines et noms d'hôtes qui :
  
−
===Install of Dehydrated rpm from smecontrib repository===
+
* sont configurés sur votre serveur KOOZALI SME (par exemple via le gestionnaire du serveur), et
−
The dehydrated script has been imported into the contribs repository and can be installed as follows:
+
* sont configurés pour utiliser Let's Encrypt.
  
−
yum --enablerepo=smecontribs install dehydrated
+
Par exemple, votre serveur KOOZALI SME peut contenir les domaines et les noms d'hôtes suivants :
  
−
The script must be configured as described below.
+
* domaine1.com
 +
** www.domaine1.com
 +
** mail.domaine1.com
 +
** ftp.domaine1.com
 +
* domaine2.com
 +
** www.domaine2.com
 +
** mail.domaine2.com
  
−
===Git install of latest version===
+
Pour chaque DOMAINE que vous voulez voir inclus dans le certificat, exécutez cette commande :
 +
db domains setprop $DOMAINE letsencryptSSLcert enabled
  
−
If you need or want the absolute latest version of the script then you can manually install as follows:
+
En utilisant l'exemple ci-dessus, une invocation de la commande ressemblerait à ceci :
 +
db domains setprop domaine1.com  letsencryptSSLcert enabled
  
−
Begin by installing git:
+
Pour chaque NOM_D_HOTE que vous voulez voir inclus dans le certificat, exécutez cette commande :
−
  yum install git
+
  db hosts setprop $NOM_D_HOTE letsencryptSSLcert enabled
  
−
Then download the Dehydrated client:
+
En utilisant l'exemple ci-dessus, une invocation de la commande ressemblerait à ceci :
−
  cd /etc
+
  db hosts setprop www.domaine1.com letsencryptSSLcert enabled
−
git clone https://github.com/lukas2511/dehydrated
 
−
mv dehydrated/dehydrated /usr/local/bin/
 
  
−
===Manual Configuration of Dehydrated===
+
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.
  
−
You'll need to create two configuration files for Dehydrated.
+
Définissez uniquement l'un des ensembles suivants.
−
  cd /etc/dehydrated
+
  config setprop letsencrypt configure domains
−
mkdir -p /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
−
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:
+
  config setprop letsencrypt configure hosts
−
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.
 
−
 
 
−
Second, you'll need to create the configuration file '''config''':
 
−
nano -w config
 
−
 
 
−
It should look like this:
 
−
#!/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 to exit, Y to save.
 
−
 
 
−
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.
 
−
 
 
−
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
 
−
 
 
−
Its contents should look like this:
 
−
#!/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 to exit, Y to save.  Then make it executable:
 
−
chmod +x /usr/local/bin/dehydrated-hook
 
−
 
 
−
You'll also need to create a custom template fragment for 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
 
−
 
 
−
The contents of that file should look like:
 
−
# Alias for letsencrypt
 
−
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 
−
Again, Ctrl-X to exit, Y to save.
 
−
 
 
−
Expand the template and restart apache:
 
−
expand-template /etc/httpd/conf/httpd.conf
 
−
service httpd-e-smith restart
 
−
 
 
−
Now you're ready to run dehydrated and get your certificate.
 
−
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
 
−
config show modSSL
 
−
and make sure there are values set for crt, key, and CertificateChainFile.
 
−
 
 
−
If dehydrated ran successfully in test mode, comment out the CA= line in /etc/dehydrated/config and run
 
−
dehydrated -c -x
 
−
 
 
−
to obtain trusted a trusted certificate.
 
−
 
 
−
===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
 
−
 
 
−
Enter the following in this file:
 
−
#!/bin/bash
 
−
/usr/bin/dehydrated -c
 
−
Ctrl-X to exit, Y to save.  Then make it executable:
 
−
chmod +x /etc/cron.daily/call-dehydrated
 
−
 
 
−
{{warning box| end of the manual installation and configuration of dehydrated without smeserver-letsencrypt contrib}}
 
−
 
 
−
==Requiring SSL==
 
−
Whether you used the contrib, or configured dehydrated manually, you'll probably want to configure your server to force secure web connections.  For any i-bays, you can do this using the server-manager page, or using a shell command.  For the Primary i-bay, you'll need to use the shell command:
 
−
db accounts setprop {accountname} SSL enabled
 
−
or
 
−
db accounts setprop Primary SSL enabled
 
−
 
−
==Backup==
 
−
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
 
−
Include=/etc/dehydrated
 
−
 
 
−
to the Affa configuration file.
 
−
 
 
−
== 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
 
  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.
+
Pour utiliser des hôtes ou des domaines activés individuellement, laissez le paramètre par défaut « none ».
  
−
To resolve this, issue the following command:
 
 
  config setprop letsencrypt configure none
 
  config setprop letsencrypt configure none
  
−
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:
+
Avec la configuration du système décrite ci-dessus :
−
db domains setprop domain1.com letsencryptSSLcert enabled
+
* la définition de « domains » obtiendra un certificat couvrant domain1.com et domain2.com, mais pas www.domain1.com, etc. ;
−
and for each hostname:
+
* 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 ;
−
db hosts setprop www.domain1.com letsencryptSSLcert enabled
+
* 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 cette [[Letsencrypt/Troubleshooting#Some_challenges_complete_successfully_but_some_hostnames_fail | NOTE en anglais]] avant de régler ce paramètre sur « all ».'''
  
−
db hosts setprop mail.domain1.com letsencryptSSLcert enabled
+
====Activer le mode test ====
−
until all the public facing hostnames are enabled
+
Après avoir installé et configuré tous les domaines et hôtes, l'étape suivante consiste à utiliser le mode test, qui est activé par défaut. Cela procurera des certificats du serveur intermédiaire. Les limites renouvellement exposées dans l'introduction ne s'appliqueront pas, donc toute erreur ou tout autre problème ne vous empêcheront pas d'obtenir votre certificat de production.
−
followed by:
+
Activer le mode test en utilisant cette commande :
 +
config setprop letsencrypt status test
 
  signal-event console-save
 
  signal-event console-save
  
−
Thanks to MSmith for the following forum thread.
+
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 :
  
−
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
 
  dehydrated -c
  
−
and your challenges should complete.
+
S'il s'imprime uniquement "# INFO: Using main config file /etc/dehydrated/config"" et vous renvoie à l'invite du shell, voir [[Bugzilla:10300]].
  
−
https://forums.contribs.org/index.php/topic,53147.0.html
+
{{Note box|type=Note :| solution pour l'erreur « ID de compte mal formé dans l'URL d'en-tête KeyID » à l'aide de l'API 2, pour les versions de contribution 0.6.13 ou antérieures, voir [[Bugzilla: 10828]] ou mettre à jour la contribution.}}
  
−
==Advanced Topics==
+
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.
−
===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
+
====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 :
  
−
  mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt
+
  config setprop letsencrypt status enabled
−
  nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname
+
signal-event console-save
 +
 +
Procurez-vous ensuite un nouveau certificat à partir du serveur de production Let's Encrypt :
 +
  dehydrated -c -x
  
−
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:
+
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.
  
−
hostname.domain.tld
+
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étuellement.
  
−
Then Ctrl-X to exit, Y to save.
+
Une fois que vous avez obtenu votre certificat et configuré votre serveur, testez votre serveur avec un outil comme [https://www.ssllabs.com/ssltest/ SSLLabs.com] pour vous assurer qu'il fonctionne correctement.
  
−
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.
+
====Archiver les vieux certificats====
  
−
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/
+
Une nouvelle fonction vous permet de nettoyer les vieux certificats et de les archiver.
−
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.
+
  dehydrated --cleanup (-gc)
  
−
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:
+
===Paramètres de configuration===
 +
{| class="wikitable"
 +
!Clé
 +
!propriété
 +
!par défaut
 +
!valeurs
 +
!
 +
|-
 +
| rowspan="10" |letsencrypt
 +
|ACCEPT_TERMS
 +
|
 +
|empty, yes
 +
|configurer à « yes » pour accepter les termes du service ; si le paramètre est laissé à « empty », la contribution ne fonctionnera pas.
 +
|-
 +
|API
 +
|2
 +
|1, 2
 +
|obsolète, sera toujours v2, car v1 est obsolète depuis juin 2021.
 +
|-
 +
|configure
 +
|none
 +
|none, all, domains, hosts
 +
|cela changera le comportement par défaut sur les domaines ou les hôtes non explicites avec « letsencryptSSLcert enabled ». Par défaut, ne sera pas utilisé : si « hosts » est défini, demandera un certificat pour tous les hôtes ; si « domains » est définis, demandera un certificat pour tous les domaines ; si « all » est défini, demandera un certificat à la fois pour tous les domaines et pour tous les hôtes. Dans toutes les situations, il demandera un certificat pour les domaines/hôtes où « letsencryptSSLcert enabled » est défini et rien si « letsencryptSSLcert disabled » est défini.
 +
|-
 +
|email
 +
|
 +
|email
 +
|entrer l'adresse courriel pour créer le compte et recevoir des mises à jour de Let's Encrypt.
 +
|-
 +
|hookScript
 +
|disabled
 +
|enabled, disabled
 +
|déclenchera un script hook avancé s'il est activé, même s'il est désactivé, la partie signal-event ssl-update pour propager le certificat s'exécutera.
 +
|-
 +
|hostOverride
 +
|disabled
 +
|yes, disabled
 +
|désactivé par défaut. S'il est désactivé, il ne demandera que le certificat pour les hôtes (si sélectionné selon la configuration et avec « letsencryptSSLcert enabled ») pour les hôtes avec type=Self. Si défini sur « yes », inclura tous les hôtes répertoriés, qu'ils soient distants ou locaux.
 +
|-
 +
|keysize
 +
|4096
 +
|base 2 number
 +
|longueur de la clé privée de votre certificat si vous ne voulez pas la '''valeur par défaut de 4096''' bits. Ce ne sera pas nécessaire dans la majorité des cas mais, si c'est désiré, utilisez cette commande pour le faire.
 +
|-
 +
|status
 +
|test
 +
|enabled, disabled, test
 +
|par défaut, le statut est désactivé. '''Dans un premier temps, configurez sur « test »''' pour se connecter au serveur de test de Let's Encrypt afin de vérifier si votre serveur est bien configuré. Après avoir vérifié que tout va bien, vous pouvez configurer le statut sur « enabled ».
 +
|}
  
−
{
+
==Dépannage==
−
    use strict;
+
Voir cette [[Letsencrypt/Troubleshooting |page (en anglais).]]
−
    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:
+
==Fonctions avancées==
 +
Voir cette [[Letsencrypt/Advanced/fr |page.]]
  
−
{
+
==Désinstallation==
−
    use strict;
+
  yum remove smeserver-letsencrypt  letsencrypt
−
    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 =
+
= Bogues =
−
Please raise bugs under the SME-Contribs section in [http://bugs.contribs.org/enter_bug.cgi bugzilla]
+
Veuillez ouvrir des bogues dans la section SME-Contribs dans [http://bugs.contribs.org/enter_bug.cgi bugzilla]
−
and select the smeserver-letsencrypt component or use {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=this link}}
+
et sélectionner le composant smeserver-letsencrypt ou utiliser {{BugzillaFileBug|product=SME%20Contribs|component=smeserver-letsencrypt|title=ce lien.}}
  
 
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}
 
{{#bugzilla:columns=id,product,version,status,summary |sort=id |order=desc |component=smeserver-letsencrypt |disablecache=1|noresultsmessage="No open bugs found."}}
  
−
= Changelog =
+
= Journal des modifications =
−
Only released version in smecontrib are listed here.
+
Seules les versions publiées dans le dépôt smecontrib sont rapportées ici.
  
 
{{#smechangelog:smeserver-letsencrypt}}
 
{{#smechangelog:smeserver-letsencrypt}}
  
−
[[Category:Howto/fr]] [[Category:Security]]
+
[[Category:Contrib/fr]]
 +
[[Category:Howto/fr]]  
 +
[[Category:Security]]
 
[[Category: Administration:Certificates]]
 
[[Category: Administration:Certificates]]

Latest revision as of 17:38, 15 December 2023

Geographylogo.png Languages: 

English  • français


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




letsencrypt
NeedImage.svg
letsencrypt logo
MaintainerJohn Crisp
Urlhttps://github.com/dehydrated-io/dehydrated
LicenceMIT license
Category

certificates

Tags dehydrated, letsencrypt, dns, http, ssl


Mainteneur

John Crisp

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.



Description

Warning.png Attention !
Le protocole original utilisé par Let’s Encrypt pour l’émission et la gestion des certificats est appelé ACMEv1. En mars 2018, Letsencrypt a introduit le support pour ACMEv2, une version plus récente du protocole qui correspond à ce qui a été finalisé aujourd'hui sous la RFC 8555 328. Ils encouragent les abonnés à passer au protocole ACMEv2.

En mars 2019, ils ont annoncé un plan de fin de vie pour ACMEv1.

En novembre 2019, ils ne permettront plus les nouvelles inscriptions de compte via leur point de terminaison API ACMEv1. 'IMPORTANT' Les comptes existants continueront à fonctionner normalement.

En juin 2020, ils ne permettront plus aux nouveaux domaines d'être validés via ACMEv1.

À compter du début de 2021, ils désactiveront occasionnellement l'émission et le renouvellement d'ACMEv1 pour des périodes de 24 heures, pas plus d'une fois par mois (le service OCSP ne sera pas affecté). Le but est d’induire des erreurs client susceptibles d’encourager les abonnés à se mettre à jour vers des clients ou des configurations utilisant ACMEv2.

Les échecs de renouvellement doivent être limités car les nouvelles validations de domaine seront déjà désactivées et nous recommandons de renouveler les certificats 30 jours avant leur expiration.

En juin 2021, ils désactiveront complètement ACMEv1 en tant que moyen viable d’obtenir un certificat Let’s Encrypt.


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 letsencrypt

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. 

yum install smeserver-letsencrypt

Vous aurez ensuite besoin de configurer les domaines et les hôtes pour lesquels vous voulez demander un certificat. Voir la section suivante « Configuration ».

Si votre dépôt « smeaddons » a été désactivé, ajoutez «  --enablerepo=smeaddons » et réactivez-le, comme il devrait l'être par défaut. 

db yum_repositories setprop smeaddons status enabled
signal-event yum-modify

Installation

yum install smeserver-letsencrypt
signal-event console-save

Vous aurez ensuite besoin de configurer les domaines et les hôtes pour lesquels vous voulez demander un certificat. Voir la section suivante « Configuration ». Si votre dépôt « smeaddons » a été désactivé, ajoutez «  --enablerepo=smeaddons » et réactivez-le, comme il devrait l'être par défaut. 

db yum_repositories setprop smeaddons status enabled
signal-event yum-modify

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 » :


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
config setprop letsencrypt ACCEPT_TERMS yes
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.

Exemples de démarrage rapide

Pour le test (régler les domaines et les hôtes) : 

config setprop letsencrypt ACCEPT_TERMS yes status test
# tâche très rapide pour activer le domaine principal :
db domains setprop $(config get DomainName) letsencryptSSLcert enabled
#pour chacun de vos domaines pour lesquels vous voulez le SSL, faites :
db domains setprop domain1.com letsencryptSSLcert enabled
#pour chacun de vos hôtes (sous-domaines) pour lesquels vous voulez le SSL, faites :
db hosts setprop www.domain1.com letsencryptSSLcert enabled
signal-event smeserver-letsencrypt-update
dehydrated -c

config setprop letsencrypt ACCEPT_TERMS yes status test API 2
#pour chacun de vos domaines pour lesquels vous voulez le SSL, faites :
db domains setprop domain1.com letsencryptSSLcert enabled
#pour chacun de vos hôtes (sous-domaines) pour lesquels vous voulez le SSL, faites :
db hosts setprop www.domain1.com letsencryptSSLcert enabled
signal-event console-save
dehydrated -c

Vérifiez que les certificats sont valables (votre fureteur détectera encore une erreur mais vous pouvez explorer le contenu du certificat pour voir que l'Autorité de Certification (CA en anglais) a été utilisée pour signer votre certificat SSL et que tous vos domaines et hôtes sont dans la propriété « Autre nom de l'objet du certificat ».

Pour la production (régler votre adresse électronique): 

config setprop letsencrypt status enabled email admin@$(config get DomainName)
signal-event smeserver-letsencrypt-update
dehydrated -c -x

config setprop letsencrypt status enabled email admin@domain1.com
signal-event console-save
dehydrated -c -x

Configuration étape par étape

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 cette NOTE en anglais avant de régler ce paramètre sur « all ».

Activer le mode test

Après avoir installé et configuré tous les domaines et hôtes, l'étape suivante consiste à utiliser le mode test, qui est activé par défaut. Cela procurera des certificats du serveur intermédiaire. Les limites renouvellement exposées dans l'introduction ne s'appliqueront pas, donc toute erreur ou tout autre problème ne vous empêcheront 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.


Important.png Note :
solution pour l'erreur « ID de compte mal formé dans l'URL d'en-tête KeyID » à l'aide de l'API 2, pour les versions de contribution 0.6.13 ou antérieures, voir Bugzilla: 10828 ou mettre à jour la contribution.


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

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)

Paramètres de configuration

Clé propriété par défaut valeurs
letsencrypt ACCEPT_TERMS empty, yes configurer à « yes » pour accepter les termes du service ; si le paramètre est laissé à « empty », la contribution ne fonctionnera pas.
API 2 1, 2 obsolète, sera toujours v2, car v1 est obsolète depuis juin 2021.
configure none none, all, domains, hosts cela changera le comportement par défaut sur les domaines ou les hôtes non explicites avec « letsencryptSSLcert enabled ». Par défaut, ne sera pas utilisé : si « hosts » est défini, demandera un certificat pour tous les hôtes ; si « domains » est définis, demandera un certificat pour tous les domaines ; si « all » est défini, demandera un certificat à la fois pour tous les domaines et pour tous les hôtes. Dans toutes les situations, il demandera un certificat pour les domaines/hôtes où « letsencryptSSLcert enabled » est défini et rien si « letsencryptSSLcert disabled » est défini.
email email entrer l'adresse courriel pour créer le compte et recevoir des mises à jour de Let's Encrypt.
hookScript disabled enabled, disabled déclenchera un script hook avancé s'il est activé, même s'il est désactivé, la partie signal-event ssl-update pour propager le certificat s'exécutera.
hostOverride disabled yes, disabled désactivé par défaut. S'il est désactivé, il ne demandera que le certificat pour les hôtes (si sélectionné selon la configuration et avec « letsencryptSSLcert enabled ») pour les hôtes avec type=Self. Si défini sur « yes », inclura tous les hôtes répertoriés, qu'ils soient distants ou locaux.
keysize 4096 base 2 number longueur de la clé privée de votre certificat si vous ne voulez pas la valeur par défaut de 4096 bits. Ce ne sera pas nécessaire dans la majorité des cas mais, si c'est désiré, utilisez cette commande pour le faire.
status test enabled, disabled, test par défaut, le statut est désactivé. Dans un premier temps, configurez sur « test » pour se connecter au serveur de test de Let's Encrypt afin de vérifier si votre serveur est bien configuré. Après avoir vérifié que tout va bien, vous pouvez configurer le statut sur « enabled ».

Dépannage

Voir cette page (en anglais).

Fonctions avancées

Voir cette page.

Désinstallation

yum remove smeserver-letsencrypt  letsencrypt


Bogues

Veuillez ouvrir des bogues dans la section SME-Contribs dans bugzilla et sélectionner le composant smeserver-letsencrypt ou utiliser ce lien.


IDProductVersionStatusSummary (10 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

Journal des modifications

Seules les versions publiées dans le dépôt smecontrib sont rapportées ici.

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]
Retrieved from "https://wiki.koozali.org/index.php?title=Letsencrypt/fr&oldid=42416"