5334
Commentaire:
|
5344
#OTL Vous confirmez le s/stanalone/standalone/ ?
|
Texte supprimé. | Texte ajouté. |
Ligne 9: | Ligne 9: |
On va expliquer ici comment obtenir un certificat valide pour la plupart des logiciels pour autre chose que du `https` (`imap`, `smtp`, `xmpp`, …) où si vous ne pouvez pas faire pointer le nom à faire passer en `https` vers `proxy.crans.org` (par exemple pour `gitlab.crans.org` auquel on accède à la fois en `https` et en `ssh`). | On va expliquer ici comment obtenir un certificat valide pour la plupart des logiciels pour autre chose que du `https` (`imap`, `smtp`, `xmpp`…) où si vous ne pouvez pas faire pointer le nom à faire passer en `https` vers `proxy.crans.org` (par exemple pour `gitlab.crans.org` auquel on accède à la fois en `https` et en `ssh`). |
Ligne 11: | Ligne 11: |
L'autorité de certification (AC) reconnue actuellement utilisé par le Crans pour ses services publiques est [[https://letsencrypt.org|Let's Encrypt]]. Pour ses services interne (essentiellement, tout ce qui est sur le [[CransTechnique/AdminRéseau/VLAN#Les_VLANs_au_Crans|vlan adm]]), le Crans utilise toujours [[CransTechnique/CaCert|CaCert]]. | L'autorité de certification (AC) reconnue actuellement utilisée par le Crans pour ses services publiques est [[https://letsencrypt.org|Let's Encrypt]]. Pour ses services internes (essentiellement, tout ce qui est sur le [[CransTechnique/AdminRéseau/VLAN#Les_VLANs_au_Crans|vlan adm]]), le Crans utilise toujours [[CransTechnique/CaCert|CaCert]]. |
Ligne 15: | Ligne 15: |
* se connecter en ssh sur `zamok.crans.org` et lancer `crans`. * Choisisser `Modifier une machine existante`, trouver la machine avec une adresse ip publique (pour être accessible depuis internet il faut une ip publique). |
* Se connecter en ssh sur `zamok.crans.org` et lancer `crans`. * Choisir `Modifier une machine existante`, trouver la machine avec une adresse ip publique (pour être accessible depuis internet il faut une ip publique). |
Ligne 18: | Ligne 18: |
* Attendez un run de generate.py sur `odlyd.crans.org` oubien : | * Attendre un run de generate.py sur `odlyd.crans.org` ou bien : |
Ligne 21: | Ligne 21: |
* Ensuite, ajoutez le groupe `letsencrypt` à la machine dans bcfg2. | * Ensuite, ajouter le groupe `letsencrypt` à la machine dans bcfg2. |
Ligne 23: | Ligne 23: |
* Aller dans `/bcfg2/Metadata` et éditez le fichier `groups.xml` | * Aller dans `/bcfg2/Metadata` et éditer le fichier `groups.xml` |
Ligne 32: | Ligne 32: |
* Lancer un run de bcfg2 (`sudo bcfg2 -I -q`) qui va ajouter les dépots `backports` où se trouve le binaire `certbot` qui est le client letsencrypt. * Mettez a jour la liste des paquets: `sudo apt-get update` * Relancer un run de bcfg2 (`sudo bcfg2 -I -q`), il devrait normalement alors installer le paquet `certbot`. Le paquet n'est pas disponible sous wheezy pour les machines pas encore à jour. Il convient donc alors d'utiliser le script `/usr/scripts/src/letsencrypt/certbot-auto` en lieu et place de la commande `cerbot` dans ce qui suit. |
* Lancer un run de bcfg2 (`sudo bcfg2 -I -q`) qui va ajouter les dépôts `backports` où se trouve le binaire `certbot` qui est le client letsencrypt. * Mettre à jour la liste des paquets : `sudo apt-get update` * Relancer un run de bcfg2 (`sudo bcfg2 -I -q`), il devrait alors normalement installer le paquet `certbot`. Le paquet n'est pas disponible sous wheezy pour les machines pas encore à jour. Il convient donc alors d'utiliser le script `/usr/scripts/src/letsencrypt/certbot-auto` en lieu et place de la commande `cerbot` dans ce qui suit. |
Ligne 36: | Ligne 36: |
* Normalement, bcfg2 devrait avoir créer un fichier de configuration pour générer le certificat letsencrypt dans `/etc/letsencrypt/conf.d/localhost.ini`. Regardez le fichier pour voir s'il correspond bien au certificat que vous souhaitez générer (notemment le paramètre `domains`). Vous pouvez aussi vérifier le paramètre `authenticator`. Il devrait valoir `webroot` si nginx est installé sur la machine et `stanalone` sinon. | * Normalement, bcfg2 devrait avoir créé un fichier de configuration pour générer le certificat letsencrypt dans `/etc/letsencrypt/conf.d/localhost.ini`. Regardez le fichier pour voir s'il correspond bien au certificat que vous souhaitez générer (notamment le paramètre `domains`). Vous pouvez aussi vérifier le paramètre `authenticator`. Il devrait valoir `webroot` si nginx est installé sur la machine et `standalone` sinon. |
Ligne 38: | Ligne 38: |
* Si nginx est installé sur la machine, vous devez ajouter `include "snippets/letsencrypt-webroot.conf";` à tous les sites activé dans `/etc/nginx/sites-enabled`. | * Si nginx est installé sur la machine, vous devez ajouter `include "snippets/letsencrypt-webroot.conf";` à tous les sites activés dans `/etc/nginx/sites-enabled`. |
Ligne 42: | Ligne 42: |
* Ce certificat est valide 90 jours. Il conviendra de le renouveller tous les 60 jours (lors qu'il restera strictement moins de 30 jours de validité) | * Ce certificat est valide 90 jours. Il conviendra de le renouveler tous les 60 jours (lorsqu'il restera strictement moins de 30 jours de validité) |
Ligne 46: | Ligne 46: |
Appliquer exactement la même procédure que pour obtenir un certificat. Normalement les deux premiers points (ouvrir le port 80 et mettre `letsencrypt` dans bcfg2) sont déjà fait. C'est la également la marche à suivre si on veut ajouter un nom au certificat. Pour retirer un nom au certificat, le client ne sais pas encore le faire, il faut donc supprimer les fichiers lié au certificat dans `/etc/letsencrypt/live`, `/etc/letsencrypt/archive` et `/etc/letsencrypt/renewal`, sinon, le client crée un doublon dont le nom se termine par -0001. | Appliquer exactement la même procédure que pour obtenir un certificat. Normalement les deux premiers points (ouvrir le port 80 et mettre `letsencrypt` dans bcfg2) sont déjà fait. C'est la également la marche à suivre si on veut ajouter un nom au certificat. Pour retirer un nom au certificat, le client ne sais pas encore le faire, il faut donc supprimer les fichiers liés au certificat dans `/etc/letsencrypt/live`, `/etc/letsencrypt/archive` et `/etc/letsencrypt/renewal`, sinon, le client crée un doublon dont le nom se termine par -0001. |
Ligne 49: | Ligne 49: |
Sur les machines du groupe `letsencrypt` (autre que le proxy https) un cron (`/etc/cron.d/letsencrypt`) est automatiquement installé qui exécute `certbot renew -q` tout les jours. Le comportement est le suivant : Si un certificat expire dans moins de 30 jours, alors on le renouvelle avec les même paramètres que la dernière fois qu'il a été généré manuellement. | Sur les machines du groupe `letsencrypt` (autre que le proxy https) un cron (`/etc/cron.d/letsencrypt`) est automatiquement installé qui exécute `certbot renew -q` tous les jours. Le comportement est le suivant : si un certificat expire dans moins de 30 jours, alors on le renouvelle avec les mêmes paramètres que la dernière fois qu'il a été généré manuellement. |
Ligne 51: | Ligne 51: |
Les renouvellements ne sont pas compté dans le ratelimit qui limite le nombre de certificat par `second level domain`, mais ont une limite différente: pour chaque certificat qui a déjà été émis, on peut générer jusqu'à 5 certificats par semaines avec le même ensemble de nom dans les `subject alt names`. | Les renouvellements ne sont pas comptés dans le ratelimit qui limite le nombre de certificats par `second level domain`, mais ont une limite différente : pour chaque certificat qui a déjà été émis, on peut générer jusqu'à 5 certificats par semaines avec le même ensemble de noms dans les `subject alt names`. |
Ligne 53: | Ligne 53: |
Un autre cron, `/etc/cron.d/letsencrypt_check_cert` vérifie que le dernier certificat généré est bien celui utilisé par l'application, et sinon, redémarre/recharge l'application pour quelle utilise le dernier certificat. | Un autre cron, `/etc/cron.d/letsencrypt_check_cert` vérifie que le dernier certificat généré est bien celui utilisé par l'application, et sinon, redémarre/recharge l'application pour qu'elle utilise le dernier certificat. |
Uniquement https ?
Si vous chercher uniquement à passer un site web de http à https, merci de consulter la page CentralisationHttps
On va expliquer ici comment obtenir un certificat valide pour la plupart des logiciels pour autre chose que du https (imap, smtp, xmpp…) où si vous ne pouvez pas faire pointer le nom à faire passer en https vers proxy.crans.org (par exemple pour gitlab.crans.org auquel on accède à la fois en https et en ssh).
L'autorité de certification (AC) reconnue actuellement utilisée par le Crans pour ses services publiques est Let's Encrypt. Pour ses services internes (essentiellement, tout ce qui est sur le vlan adm), le Crans utilise toujours CaCert.
Obtention d'un certificat
- Pour obtenir un certificat pour une machine, il faut comme pré-requis que cette machine soit accessible depuis internet sur le port 80. Il faut donc ouvrir le port entrant sur le pare-feu. Pour cela :
Se connecter en ssh sur zamok.crans.org et lancer crans.
Choisir Modifier une machine existante, trouver la machine avec une adresse ip publique (pour être accessible depuis internet il faut une ip publique).
Aller dans le menu Information et mettre le port 80 dans Port TCP ouvert vers l'extérieur.
Attendre un run de generate.py sur odlyd.crans.org ou bien :
Se connecter en ssh sur odlyd.crans.org
Lancer sudo /usr/scripts/gestion/gen_confs/generate.py
Ensuite, ajouter le groupe letsencrypt à la machine dans bcfg2.
Se connecter en ssh sur bcfg2.adm.crans.org
Aller dans /bcfg2/Metadata et éditer le fichier groups.xml
Chercher la définition du groupe de la machine et y ajouter le groupe letsencrypt, par exemple pour geet.crans.org:
<Group name="geet" profile="true"> […] <Group name="letsencrypt"/> </Group>
- Se connecter en ssh sur la machine et y effectuer les opérations suivantes :
Lancer un run de bcfg2 (sudo bcfg2 -I -q) qui va ajouter les dépôts backports où se trouve le binaire certbot qui est le client letsencrypt.
Mettre à jour la liste des paquets : sudo apt-get update
Relancer un run de bcfg2 (sudo bcfg2 -I -q), il devrait alors normalement installer le paquet certbot. Le paquet n'est pas disponible sous wheezy pour les machines pas encore à jour. Il convient donc alors d'utiliser le script /usr/scripts/src/letsencrypt/certbot-auto en lieu et place de la commande cerbot dans ce qui suit.
Normalement, bcfg2 devrait avoir créé un fichier de configuration pour générer le certificat letsencrypt dans /etc/letsencrypt/conf.d/localhost.ini. Regardez le fichier pour voir s'il correspond bien au certificat que vous souhaitez générer (notamment le paramètre domains). Vous pouvez aussi vérifier le paramètre authenticator. Il devrait valoir webroot si nginx est installé sur la machine et standalone sinon.
Si nginx est installé sur la machine, vous devez ajouter include "snippets/letsencrypt-webroot.conf"; à tous les sites activés dans /etc/nginx/sites-enabled.
Lancer sudo certbot --config /etc/letsencrypt/conf.d/localhost.ini certonly pour générer la clef privée et le certificat. Ils seront alors mis dans le dossier /etc/letsencrypt/live/_nom_de_la_machine/.
- Ce certificat est valide 90 jours. Il conviendra de le renouveler tous les 60 jours (lorsqu'il restera strictement moins de 30 jours de validité)
Renouvellement d'un certificat
Manuellement
Appliquer exactement la même procédure que pour obtenir un certificat. Normalement les deux premiers points (ouvrir le port 80 et mettre letsencrypt dans bcfg2) sont déjà fait. C'est la également la marche à suivre si on veut ajouter un nom au certificat. Pour retirer un nom au certificat, le client ne sais pas encore le faire, il faut donc supprimer les fichiers liés au certificat dans /etc/letsencrypt/live, /etc/letsencrypt/archive et /etc/letsencrypt/renewal, sinon, le client crée un doublon dont le nom se termine par -0001.
Automatiquement
Sur les machines du groupe letsencrypt (autre que le proxy https) un cron (/etc/cron.d/letsencrypt) est automatiquement installé qui exécute certbot renew -q tous les jours. Le comportement est le suivant : si un certificat expire dans moins de 30 jours, alors on le renouvelle avec les mêmes paramètres que la dernière fois qu'il a été généré manuellement.
Les renouvellements ne sont pas comptés dans le ratelimit qui limite le nombre de certificats par second level domain, mais ont une limite différente : pour chaque certificat qui a déjà été émis, on peut générer jusqu'à 5 certificats par semaines avec le même ensemble de noms dans les subject alt names.
Un autre cron, /etc/cron.d/letsencrypt_check_cert vérifie que le dernier certificat généré est bien celui utilisé par l'application, et sinon, redémarre/recharge l'application pour qu'elle utilise le dernier certificat.