Changes

Jump to navigation Jump to search
15,848 bytes removed ,  18:38, 15 December 2023
m
Line 1: Line 1:  
{{Languages|Letsencrypt}}
 
{{Languages|Letsencrypt}}
 
{{Level|Medium}}
 
{{Level|Medium}}
{{Warning box|type=<big>Attention : | PAGE EN TRAVAUX depuis le 23 août 2022 ! Consulter la page en anglais qui est à jour.</big>}}
   
<!-- here we define the contrib name variable -->
 
<!-- 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-->
 
<!-- we get the page title, remove suffix for translated version; if needed you can define there with the value you want-->
Line 122: Line 121:  
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
 
<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
 +
# 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 :
 
  #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
Line 142: Line 143:  
Pour la production ('''régler votre adresse électronique'''):
 
Pour la production ('''régler votre adresse électronique'''):
 
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
 
<tabs container style="display: inline-block;"><tab name="Pour SME 10">
  config setprop letsencrypt status enabled email '''admin@domain1.com'''
+
  config setprop letsencrypt status enabled email admin@$(config get DomainName)
 
  signal-event smeserver-letsencrypt-update
 
  signal-event smeserver-letsencrypt-update
 
  dehydrated -c -x
 
  dehydrated -c -x
Line 200: Line 201:  
* la définition de « domains » obtiendra un certificat couvrant domain1.com et domain2.com, mais pas www.domain1.com, etc. ;
 
* 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 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 ».' ''
+
* 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 ».'''
    
====Activer le mode test ====
 
====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.
 
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 :
 
Activer le mode test en utilisant cette commande :
config setprop letsencrypt status test
  −
signal-event console-save
  −
  −
====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 [[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]]
  −
puis exécutez :
  −
config setprop letsencrypt ACCEPT_TERMS yes
  −
{{Note box|type=Note : | la création d'un nouveau certificat nécessite que l'API soit définie sur V2, voir l'avertissement ci-dessus.}}
  −
  −
===V2 API===
  −
Avec la dernière version de letsencrypt / deshydrated, l'API V2 est nécessaire pour créer de nouveaux certificats. La version 1 est déconseillée pour la création de nouveaux certificats, mais elle reste valable pour les certificats existants créés avec elle.
  −
  −
La clé s'appelle API. La valeur par défaut est « 1 » si elle n'est pas définie. Les options sont « 1 », « 2 », « auto ».
  −
  −
Pour mettre à jour les certificats V1 actuels, laissez la valeur par défaut ou définissez-la sur « 1 », « auto ».
  −
  −
# config show letsencrypt
  −
letsencrypt=service
  −
    ACCEPT_TERMS=yes
  −
    configure=none
  −
    email=####@#####.###
  −
    hookScript=disabled
  −
    status=enabled
  −
  −
# config setprop letsencrypt API 1
  −
# signal-event console-save
  −
  −
# config show letsencrypt
  −
letsencrypt=service
  −
    ACCEPT_TERMS=yes
  −
    API=1
  −
    configure=none
  −
    email=####@#####.###
  −
    hookScript=disabled
  −
    status=enabled
  −
  −
Pour créer un nouveau certificat ou mettre à jour une configuration V2 à 2 :
  −
  −
# config setprop letsencrypt API 2
  −
# signal-event console-save
  −
  −
# config show letsencrypt
  −
letsencrypt=service
  −
    ACCEPT_TERMS=yes
  −
    API=2
  −
    configure=none
  −
    email=####@#####.###
  −
    hookScript=disabled
  −
    status=enabled
  −
  −
===Activer le mode test ===
  −
L'étape suivante consiste à activer le mode test. Cela va obtenir des certificats du serveur d'étape. Les limites de quantité présentées dans l'introduction ne s'appliqueront pas, donc toute erreur ou autre problème ne vous empêchera pas d'obtenir votre certificat de production. Activer le mode test en utilisant cette commande :
  −
   
  config setprop letsencrypt status test
 
  config setprop letsencrypt status test
 
  signal-event console-save
 
  signal-event console-save
Line 277: Line 215:  
S'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]].
   −
{{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.}}
+
{{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.}}
    
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.
   −
===Activer le mode 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 :
 
Une fois que vous avez testé avec succès votre installation, réglez-la en mode production en utilisant les commandes suivantes :
   Line 292: Line 230:  
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.
 
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étuellement.
    
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.
 
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.
===Archiver les vieux certificats===
+
 
 +
====Archiver les vieux certificats====
    
Une nouvelle fonction vous permet de nettoyer les vieux certificats et de les archiver.
 
Une nouvelle fonction vous permet de nettoyer les vieux certificats et de les archiver.
Line 301: Line 240:  
  dehydrated --cleanup (-gc)
 
  dehydrated --cleanup (-gc)
   −
===Exemples de démarrage rapide===
+
===Paramètres de configuration===
Pour le test ('' 'ajuster les domaines et les hôtes' '') :
+
{| class="wikitable"
  config setprop letsencrypt ACCEPT_TERMS yes status test API 2
+
!Clé
  #pour chacun de vos domaines où vous voulez SSL, faire ce qui suit :
+
!propriété
  db domains setprop '''domaine1.com''' letsencryptSSLcert enabled
+
!par défaut
  #pour chacun de vos hôtes (sous-domaines) où vous voulez SSL, faire ce qui suit :
+
!valeurs
  db hosts setprop '''www.domaine1.com''' letsencryptSSLcert enabled
+
!
  signal-event console-save
+
|-
  dehydrated -c
+
| rowspan="10" |letsencrypt
 
+
|ACCEPT_TERMS
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 ».
+
|
 
+
|empty, yes
Pour la production ('' 'ajustez votre adresse courriel' '') :
+
|configurer à « yes » pour accepter les termes du service ; si le paramètre est laissé à « empty », la contribution ne fonctionnera pas.
 
+
|-
config setprop letsencrypt status enabled email '''admin@domaine1.com'''
+
|API
signal-event console-save
+
|2
dehydrated -c -x
+
|1, 2
 
+
|obsolète, sera toujours v2, car v1 est obsolète depuis juin 2021.
 
+
|-
==Imposer le SSL ==
+
|configure
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 :
+
|none
 
+
|none, all, domains, hosts
db accounts setprop {accountname} SSL enabled
+
|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.
ou
+
|-
db accounts setprop Primary SSL enabled
+
|email
+
|
==Sauvegarde ==
+
|email
Votre certificat, votre clé privée et d'autres informations importantes sont stockés dans /etc/dehydrated, ce qui n'est pas inclus dans les routines de sauvegarde normale du serveur KOOZALI SME. Assurez-vous d'ajouter ce répertoire à vos sauvegardes. Voir, par exemple, [[Backup with dar#Adding_Files_and_Directories|Sauvegardes avec dar]] si vous utilisez la fonction de sauvegarde de poste de travail.
+
|entrer l'adresse courriel pour créer le compte et recevoir des mises à jour de Let's Encrypt.
Assurez-vous que le « / » de début dans /etc/dehydrated est supprimé lorsque vous créez votre fichier d'inclusion. Sinon, des erreurs d'analyse se produisent.
+
|-
 
+
|hookScript
Si vous utilisez Affa pour la sauvegarde, ajoutez :
+
|disabled
 
+
|enabled, disabled
Include=/etc/dehydrated
+
|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.
 
+
|-
au fichier de configuration d'Affa.
+
|hostOverride
 
+
|disabled
== Troubleshooting ==
+
|yes, disabled
===Certificate Errors===
+
|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.
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)
+
|keysize
config setprop modSSL key (old value)
+
|4096
config setprop modSSL CertificateChainFile (old value--if this property was empty, delete it using the command line below)
+
|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.
If you did not have custom settings for modSSL, remove your changes with:
+
|-
config delprop modSSL crt
+
|status
config delprop modSSL key
+
|test
config delprop modSSL CertificateChainFile
+
|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 ».
Once you've made these changes, do:
+
|}
signal-event post-upgrade
  −
signal-event reboot
  −
 
  −
Also see
  −
 
  −
https://wiki.contribs.org/Useful_Commands#How_to_simply_recreate_the_certificate_for_SME_Server
  −
 
  −
rm /home/e-smith/ssl.{crt,key,pem}/*
  −
config delprop modSSL CommonName
  −
config delprop modSSL crt
  −
config delprop modSSL key
  −
signal-event post-upgrade
  −
signal-event reboot
  −
 
  −
===Authorization Errors===
  −
The first thing is to check all your domains can resolve
  −
 
  −
http://my.domain/.well-known/acme-challenge
  −
 
  −
Check that the following files are correctly generated
  −
 
  −
/etc/dehydrated/config
  −
/etc/dehydrated/domains.txt
  −
 
  −
Set letsencrypt back to test and remove any generated keys
  −
 
  −
db configuration setprop letsencrypt status test
  −
 
  −
rm /etc/dehydrated/certs/* -rf
  −
rm /etc/dehydrated/accounts/* -rf
  −
 
  −
Then run letsencrypt again
  −
 
  −
dehydrated -c
  −
 
  −
To restore the original certificates:
  −
 
  −
config delprop modSSL CertificateChainFile
  −
config delprop modSSL crt
  −
config delprop modSSL key
  −
 
  −
signal-event console-save
  −
 
  −
===Errors===
  −
 
  −
 
  −
====No registration exists matching provided key====
  −
 
  −
 
  −
If you see the following:
  −
 
  −
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}
  −
 
  −
https://github.com/lukas2511/letsencrypt.sh/issues/2
  −
 
  −
See above for removing private keys and regenerating
  −
 
  −
====rateLimited, Too many currently pending Authorizations====
  −
 
  −
If you see something like this you may have hit the rate limit:
  −
 
  −
{"type":"urn:acme:error:rateLimited","detail":"Error creating new authz :: Too many currently pending authorizations.","status":429}
  −
 
  −
https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/staging.md
  −
 
  −
https://letsencrypt.org/docs/rate-limits/
  −
 
  −
====Some challenges complete successfully but some hostnames fail====
  −
 
  −
If you see some of your challenges returned without error but some fail, you possibly do not have Public DNS A or MX records for all the host names that you are adding to your certificate.  
  −
 
  −
Using the command:
  −
config setprop letsencrypt configure all
  −
 
  −
Is likely to cause this error. When a domain is added to an SME server, several host names are created automatically. these include ftp.your-domain.com, wpad.your-domain.com, proxy.your-domain.com, mail.your-domain.com, www.your-domain.com. Most of us do not create public DNS records for all these host names. When letsencrypt issues a challenge for a list of host names and '''ONE''' does not resolve, the challenge will fail and the certificate will not generate at all.
  −
 
  −
To resolve this, issue the following command:
  −
config setprop letsencrypt configure none
  −
 
  −
Then follow up with the commands to enable letsencrypt for each PUBLIC resolvable domain and hostname:
  −
db domains setprop domain1.com letsencryptSSLcert enabled
  −
and for each hostname:
  −
db hosts setprop www.domain1.com letsencryptSSLcert enabled
  −
 
  −
db hosts setprop mail.domain1.com letsencryptSSLcert enabled
  −
until all the public facing hostnames are enabled
  −
followed by:
  −
signal-event console-save
  −
 
  −
Thanks to MSmith for the following forum thread.
  −
 
  −
https://forums.contribs.org/index.php/topic,53052.0.html
  −
 
  −
====Challenge fails with unauthorized 403 error====
  −
 
  −
If your challenge returns something like the following:
  −
ERROR: Challenge is invalid! (returned: invalid) (result: {
  −
  "type": "http-01",
  −
  "status": "invalid",
  −
  "error": {
  −
    "type": "urn:acme:error:unauthorized",
  −
    "detail": "Invalid response from http://www.your-domain.com/.well-known/acme-challenge/<redacted text>
  −
    "status": 403
  −
and your ''httpd error_log'' on your server shows something like this:
  −
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied
  −
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied
  −
(13)Permission denied: access to /.well-known/acme-challenge/<redacted> denied
  −
 
  −
You need to check the ownership and rights on ''/home/e-smith/files/ibays/Primary'' and on ''/home/e-smith/files/ibays/Primary/html''. The contrib creates a hidden working directory at ''/home/e-smith/files/ibays/Primary/html/.well-known'' and inside that directory a second directory with the following path ''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge''. The script creates the two new directories with the correct ownerships and rights, however, if the ownership and rights on the ibay and the html directory do not allow the script to access the new location, the challenge will fail with ''access denied''
  −
 
  −
use the following to check the rights:
  −
cd /home/e-smith/files/ibays
  −
then
  −
ls -l
  −
on my test server with only the Primary ibay I get the following (you will probably show a bunch more ibays on your server but we are only concerned with Primary):
  −
total 4
  −
drwxr-xr-x 5 root root 4096 Jul 25  2016 Primary
  −
 
  −
If this is not what you see, you need to correct it.
  −
 
  −
'''THIS MAY BREAK NON STANDARD CUSTOMIZATION OF YOUR SERVER, YOU NEED TO UNDERSTAND WHY THIS HAS BEEN CHANGED BEFORE YOU REVERSE IT'''
  −
 
  −
From within ''/home/e-smith/files/ibays/'' issue the following:
  −
chown root:root Primary
  −
If the rights are not correct, issue:
  −
chmod 0755 Primary
  −
 
  −
Next check the html directory.
  −
cd /home/e-smith/files/ibays/Primary
  −
then
  −
ls -l
  −
on my test server I have the following
  −
[root@backupserver Primary]# ls -l
  −
total 12
  −
drwxr-s--- 2 admin shared 4096 Jul 25  2016 cgi-bin
  −
drwxr-s--- 2 admin shared 4096 Jul 25  2016 files
  −
'''drwxr-s--- 3 admin shared 4096 Jun 11 08:06 html'''
  −
 
  −
If this is not what you see,
  −
 
  −
'''FIRST READ ABOVE WARNING'''
  −
 
  −
then adjust as follows
  −
chown admin:shared html
  −
If the rights are not correct, issue:
  −
chmod 2750 html
  −
 
  −
rerun
  −
dehydrated -c
  −
 
  −
and your challenges should complete.
  −
 
  −
https://forums.contribs.org/index.php/topic,53147.0.html
  −
 
  −
==Sujets avancés==
  −
===Obtention de certificats pour d'autres serveurs===
  −
Le client « dehydrated » peut être utilisé pour obtenir des certificats pour d'autres serveurs de votre réseau, si les noms d'hôte sont résolus (depuis l'extérieur de votre réseau) vers votre serveur SME. Voici comment procéder en utilisant la contribution smeserver-letsencrypt.
  −
 
  −
====Hôtes et domaines====
  −
{{Note box|type=Note : | pour autant que je (ReetP) sache, cette section n'est pas nécessaire. Vous devriez simplement être en mesure de définir un hôte avec « HostType local » et une adresse InternalIP comme activation de letsencryptSSLcert, puis régénérer domains.txt.}}
  −
 
  −
Vous devrez créer deux fragments de modèle : un pour ajouter votre nom d'hôte à /etc/dehydrated/domains.txt, et le second pour gérer le certificat une fois qu'il est généré. Pour créer le premier, faites :
  −
 
  −
mkdir -p /etc/e-smith/templates-custom/etc/dehydrated/domains.txt
  −
nano -w /etc/e-smith/templates-custom/etc/dehydrated/domains.txt/15Hostname
  −
 
  −
Vous pouvez remplacer «Hostname» dans «15Hostname» par un élément descriptif de l'hôte pour lequel vous voulez obtenir un certificat. Si vous souhaitez plusieurs certificats supplémentaires, créez des fragments distincts pour chacun. Dans le fichier, entrez simplement le nom de domaine complet du système :
  −
 
  −
nom_d_hote.domaine
     −
Puis Ctrl-X pour quitter, Y pour sauvegarder.
+
==Dépannage==
 +
Voir cette [[Letsencrypt/Troubleshooting |page (en anglais).]]
   −
====Déploiement du script d'accrochage====
+
==Fonctions avancées==
 +
Voir cette [[Letsencrypt/Advanced/fr |page.]]
   −
Le deuxième fragment de modèle sera une partie du script d'accrochage, ainsi le client « dehydrated » sait quoi faire avec ce certificat. Cela doit être présent, sinon « dehydrated » configurera votre serveur SME pour qu'il utilise ce certificat plutôt que le certificat pour le serveur SME.
+
==Désinstallation==
 
+
  yum remove smeserver-letsencrypt  letsencrypt
mkdir -p /etc/e-smith/templates-custom/usr/bin/hook-script.sh/
  −
nano -w 05deploy_cert_hostname
  −
 
  −
Comme ci-dessus, remplacez « hostname » par quelque chose qui décrit l'hôte auquel ce script s'appliquera. La partie numérique peut être modifiée, mais DOIT être inférieure à 10.
  −
 
  −
Au minimum, ce fragment devra reconnaître qu'il est appelé pour un certificat autre que le certificat du serveur principal et devra s'arrêter afin d'empêcher les parties ultérieures du script d'installer ce certificat en tant que certificat du serveur principal. La forme minimale de ce fragment serait :
  −
 
  −
{
  −
    use strict;
  −
    use warnings;
  −
    use esmith::ConfigDB;
  −
  −
    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");
  −
  −
    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )    || 'disabled';
  −
  −
    if ( $letsencryptStatus ne 'disabled' ) {
  −
  −
    $OUT .=<<'_EOF';
  −
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then
  −
  echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@yourdomain.com
  −
  exit 0
  −
fi
  −
_EOF
  −
  −
    }
  −
}
  −
 
  −
Selon les caractéristiques de l'autre système, ce script peut cependant installer le certificat sur ce système. Le fragment suivant copiera les fichiers du certificat sur un système Linux distant exécutant Apache pour le serveur Web et rechargera Apache pour qu'il commence à utiliser le nouveau certificat :
  −
 
  −
{
  −
    use strict;
  −
    use warnings;
  −
    use esmith::ConfigDB;
  −
  −
    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");
  −
  −
    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )    || 'disabled';
  −
  −
    if ( $letsencryptStatus ne 'disabled' ) {
  −
  −
    $OUT .=<<'_EOF';
  −
if [ $1 = "deploy_cert" ] && [ $2 = "hostname.domain.tld" ]; then
  −
  KEY=$3
  −
  CERT=$4
  −
  CHAIN=$6
  −
  scp $CERT root@hostname:/etc/pki/tls/certs/pbx.familybrown.org.crt
  −
  scp $KEY root@hostname:/etc/pki/tls/private/pbx.familybrown.org.key
  −
  scp $CHAIN root@hostname:/etc/pki/tls/certs/server-chain.crt
  −
  ssh root@pbx "/sbin/service httpd reload"
  −
  echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld
  −
  exit 0
  −
fi
  −
_EOF
  −
  −
    }
  −
}
  −
 
  −
Le fragment suivant installe le nouveau certificat sur un hôte Proxmox VE :
  −
 
  −
{
  −
    use strict;
  −
    use warnings;
  −
    use esmith::ConfigDB;
  −
  −
    my $configDB = esmith::ConfigDB->open_ro or die("can't open Config DB");
  −
  −
    my $letsencryptStatus = $configDB->get_prop( 'letsencrypt', 'status' )    || 'disabled';
  −
  −
    if ( $letsencryptStatus ne 'disabled' ) {
  −
  −
    $OUT .=<<'_EOF';
  −
if [ $1 = "deploy_cert" ] && [ $2 = "pve.domain.tld" ]; then
  −
  KEY=$3
  −
  CHAIN=$5
  −
  scp $KEY root@pve:/etc/pve/nodes/pve/pveproxy-ssl.key
  −
  scp $CHAIN root@pve:/etc/pve/nodes/pve/pveproxy-ssl.pem
  −
  ssh root@pve "systemctl restart pveproxy"
  −
  echo "$2 certificate renewed" | mail -s "Certificate renewal" admin@domain.tld
  −
  exit 0
  −
fi
  −
  _EOF
  −
  −
    }
  −
}
  −
 
  −
Une fois que vous avez créé les fragments de modèle, développez les modèles et exécutez « dehydrated » pour générer les certificats :
  −
 
  −
signal-event console-save
  −
dehydrated -c
  −
 
  −
Ces certificats seront automatiquement renouvelés, tout comme le certificat du serveur principal.
  −
 
  −
=== Obtenir des certificats pour un serveur KOOZALI SME privé ===
  −
Comme indiqué ci-dessus dans la section prérequis, votre serveur SME  doit être normalement accessible depuis Internet afin que les serveurs de Let's Encrypt puissent valider que vous le contrôlez. Toutefois, si votre serveur SME n'est pas accessible depuis Internet, la contribution smeserver-letsencrypt fournit une méthode permettant de valider le contrôle de domaine. Pour utiliser cette méthode, les conditions suivantes doivent être remplies :
  −
* le nom d'hôte de votre serveur SME interne (exemple: interne.mon-domaine.com) ​​résout, sur l'Internet public, via une adresse IP valide ;
  −
* l'hôte auquel interne.mon-domaine.com résout (exemple: passerelle.mon-domaine.com) ​​dispose d'un serveur Web actif sur le port 80 ;
  −
* l'utilisateur root de interne.mon-domaine.com peut se connecter à passerelle.mon-domaine.com via SSH sans entrer de mot de passe (c'est-à-dire que vous avez configuré l'authentification par clé publique SSH).
  −
 
  −
Cette méthode utilise un script simple inclus dans la contribution smeserver-letsencrypt, qui requiert que quatre entrées d'une base de données soient définies :
  −
 
  −
config setprop letsencrypt hookScript enabled
  −
config setprop letsencrypt host '''passerelle.mon-domaine.com'''
  −
config setprop letsencrypt user '''root'''
  −
  config setprop letsencrypt path '''/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge'''
  −
signal-event console-save
     −
Les parties en gras ci-dessus doivent être modifiées pour correspondre à votre situation ; la variable « path » devrait être l'emplacement du système de fichiers que l'hôte passerelle.mon-domaine.com mettra à disposition, comme /.well-known/acme-challenge/. Lorsque « dehydrated » crée le fichier de challenge, il le transfère via scp vers user@host: path/, puis autorise le serveur Let's Encrypt à valider. Une fois la validation effectuée, le script supprime le fichier de challenge de user@host:path/.
      
= Bogues =
 
= Bogues =
Line 641: Line 306:  
{{#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}}
3,054

edits

Navigation menu