|
Taille: 4405
Commentaire:
|
Taille: 10007
Commentaire: Update with nginx plugin
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| #format wiki #language fr #acl +All:read {{{#!wiki tip '''Autre chose que https ?''' Si vous cherchez à migrer un service n'utilisant pas `https`, peut-être voulez-vous consulter la page [[../CertificatsTLS|CertificatsTLS]] }}} |
|
| Ligne 5: | Ligne 13: |
| Avantages : | Avantages : |
| Ligne 7: | Ligne 16: |
| * Moins de surface d'exposition pour les nombreuses vm qui fournissent des sites webs | * Moins de surface d'exposition pour les nombreuses vm qui fournissent des sites web |
| Ligne 10: | Ligne 19: |
| Inconvénients : * Rajoute un single point of failure (même si redondance envisageable) |
Inconvénients : * Rajoute un ''single point of failure'' (même si redondance envisageable) |
| Ligne 16: | Ligne 26: |
| Actuellement, les serveurs "bakdaur" et "frontdaur" ont été créés afin de centraliser le https, notamment pour éviter les problèmes de [[https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769|rate-limit de la beta de letsencrypt]]: on génère un seul certificat de temps en temps, qui contient tous les noms de domaine, plutôt que pleins de petits certificats. | Actuellement, les serveurs [[CransTechnique/LesServeurs/Virtuels/ServeurBakdaur | bakdaur]] et [[CransTechnique/LesServeurs/Virtuels/ServeurFrontdaur | frontdaur]] ont été créés afin de centraliser le https, --(notamment pour éviter les problèmes de [[https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769|rate-limit de la beta de letsencrypt]] : on génère deux certificats (hostnames-a-m.crans.org et hostnames-n-z.crans.org) de temps en temps, qui contient tous les noms de domaine (maximum de 100 noms par certificats), plutôt que pleins de petits certificats.)-- Les rate limit ont été bien relevés, notamment, les limites pour les nouveaux certificats et pour les renouvellements sont disjointes. Il n'est donc plus nécessaire de générer un certificat avec tous les noms. Du coup, les certificats générés ici contiennent seulement les noms pointant vers {{{proxy.crans.org}}}. |
| Ligne 18: | Ligne 28: |
| Les deux serveurs se partagent l'adresse IP liée à {{{proxy.crans.org}}}. En fonctionnement normal, {{{bakdaur}}} possède l'ip et reste en fonction. En cas de soucis, {{{frontdaur}}} prend la main grâce à [[CransTechnique/AdminSystème/KeepAlived|Keepalived]]. Ce deuxième serveur est aussi utile pour tester le déploiement d'une nouvelle configuration nginx, avant de l'appliquer pour tout le monde. | Les deux serveurs se partagent l'adresse IP liée à {{{proxy.crans.org}}}. En fonctionnement normal, {{{bakdaur}}} possède l'ip et reste en fonction. En cas de souci, {{{frontdaur}}} prend la main grâce à [[CransTechnique/AdminSystème/KeepAlived|Keepalived]]. Ce deuxième serveur est aussi utile pour tester le déploiement d'une nouvelle configuration nginx, avant de l'appliquer pour tout le monde. |
| Ligne 20: | Ligne 30: |
| [[attachment:centralisation_ssl.svg|Un schema de principe]] résume la situation, avec deux alternatives possibles (fichiers statiques déservis par bakdaur ou le serveur initial). | [[attachment:centralisation_ssl.svg|Un schéma de principe]] résume la situation, avec deux alternatives possibles (fichiers statiques desservis par bakdaur ou le serveur initial). |
| Ligne 25: | Ligne 35: |
| === Mode webroot === On évite de couper nginx pour renouveller/générer un certif LE, on utilise le mode webroot. {{{ location /.well-known { alias /usr/share/nginx/html/.well-known; } |
La génération et le renouvellement des certificats se fait avec {{{certbot}}}. Pour réaliser un challenge HTTP-01 sans couper NGINX qui écoute déjà sur les ports 80/443, on utilise le plugin {{{python3-certbot-nginx}}}. === Générer les macro certificats === Pour le moment, la génération des certificats est a faire sur {{{bakdaur}}}. Elle requiert les droits nounou. La configuration des certificats à générer est créée automatiquement par bcfg2 dans {{{/etc/letsencrypt/conf.d/}}}. Il suffit alors de charger la nouvelle configuration dans certbot pour mettre à jour un certificat. Quand les certificats sont générés, on les copie sur {{{frontdaur}}} en lançant le script {{{/usr/scripts/utils/letsencrypt/sync-certificates}}}. Ci-dessous, la procédure étape par étape : 1. Se connecter sur {{{bakdaur}}}. 1. Lancer un run de bcfg2 pour mettre à jour la configuration des certificats avec tous les noms de domaines {{{sudo bcfg2 -I -q}}}. 1. Lancer les commandes suivantes pour générer les macro certificats pour `crans.org`, `crans.fr`, `crans.eu` et `crans.ens-cachan.fr` : 1. {{{ sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.org.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.org.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.fr.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.fr.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.eu.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.eu.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/crans.ens-cachan.fr.ini certonly |
| Ligne 32: | Ligne 62: |
| 1. Lancer {{{/usr/scripts/utils/letsencrypt/sync-certificates}}} pour copier les certificats nouvellement générés sur frontdaur. 1. Lancer `sudo service nginx reload` sur frontdaur et bakdaur pour que nginx prenne en compte les certificats nouvellement générés. |
|
| Ligne 33: | Ligne 65: |
| Le sous-dossier {{{acme-challenge}}} est utilisé par LE pour placer les challenges nécessaires à l'obtention du certificat. À terme, on placera également un lien symbolique vers {{{/etc/hostname}}}, afin de savoir rapidement en cas de test, qui de {{{backdaur}}} ou de {{{frontdaur}}} réalise le proxy pour un site (il suffira d'aller sur {{{https://nomdusite.crans.org/.well-known/hostname}}}). |
=== Renouvellement des certificats === ==== Manuellement ==== Appliquer exactement la même procédure que pour générer les certificats. Que des noms aient été ajoutés ou supprimés au certificat n'est plus important depuis l'ajout de l'option `cert-name` dans les fichiers de configurations. == Frontdaur ou Bakdaur == Un moyen simple de savoir lequel des deux serveurs est actuellement utilisé comme proxy est d'aller à l'adresse {{{https://nomdusite.crans.org/.proxy-name/hostname.txt}}}. |
| Ligne 41: | Ligne 77: |
| On suppose que l'on dispose d'un site web sur serveur du même nom, que l'on nommera "monsiteweb". | On suppose que l'on dispose d'un site web sur serveur du même nom, que l'on nommera "monsiteweb". On suppose que l'on se trouve en fonctionnement normal, c'est-à-dire {{{proxy.crans.org}}} est géré par {{{bakdaur}}} et que nous pouvons donc réaliser nos tests sur {{{frontdaur}}}. Les certificats sur frontdaur et bakdaur ne contiennent plus tous les nom de serveur crans, aussi, il sera nécessaire de renouveler le bon certificat une fois "monsiteweb" ajouté a la configuration. |
| Ligne 43: | Ligne 82: |
| 1. Configurer nginx pour délivrer le site web en http (clair) en écoutant '''uniquement''' sur l'interface adm du serveur ( {{{listen monsiteweb.adm.crans.org:80 }}}) | 1. Configurer nginx pour délivrer le site web en http (clair) en écoutant '''uniquement''' sur l'interface adm du serveur ({{{listen monsiteweb.adm.crans.org:80}}}) 1. Ajouter dans le contexte server {} les lignes suivantes pour récupérer l'ip réelle des clients et non celle du proxy . {{{ set_real_ip_from 10.231.136.0/24; set_real_ip_from 2a01:240:fe3d:c804::/64; real_ip_header P-Real-Ip; }}} Ou ceci dans le !VirtualHost si apache2 httpd est utilisé après s'être assuré que le module [[https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html|remoteip]] est activé. . {{{ RemoteIPHeader P-Real-Ip RemoteIPInternalProxy 10.231.136.0/24 RemoteIPInternalProxy 2a01:240:fe3d:c804::/64 }}} |
| Ligne 45: | Ligne 96: |
| 1. Aller sur bcfg2, régler un nouveau site à proxifier, dans {{{/bcfg2/Python/etc/nginx/sites-available/proxy}}} 1. Appliquer bcfg2 sur {{{frontdaur}}} (en supposant qu'il ne soit pas en prod à ce moment là (!)) et reloader nginx 1. Sur son ordinateur, forcer l'utilisation de frontdaur pour l'affichage de "monsiteweb", via l'ajout d'une ligne "138.231.136.144 monsiteweb.crans.org" (138.231.136.144 étant l'ip de frontdaur.crans.org) |
1. La génération du site proxy par bcfg2 avec le nouvel alias est automatique à partir du nouvel alias de la machine, il est cependant nécessaire de la faire à la main la première fois, dans {{{/bcfg2/Python/etc/nginx/sites-available/proxy}}} 1. Appliquer bcfg2 sur {{{frontdaur}}} et rechager nginx 1. Sur son ordinateur, forcer l'utilisation de {{{frontdaur}}} pour l'affichage de "monsiteweb.crans.org", via l'ajout d'une ligne "138.231.136.144 monsiteweb.crans.org" dans le {{{/etc/hosts}}} (138.231.136.144 étant l'ip de frontdaur.crans.org) |
| Ligne 49: | Ligne 100: |
| 1. Si tout s'est bien passé, on peut renommer le patte publique de "monsiteweb.crans.org" (renommer en "monsiteweb-srv.crans.org" et ajouter au groupe bcfg2 "proxied") ou supprimer l'alias, si c'en était un | 1. Si tout s'est bien passé, on applique bcfg2 sur {{{backdaur}}} 1. On renomme la patte publique de "monsiteweb.crans.org" (renommer en "monsiteweb-srv.crans.org" et ajouter au groupe bcfg2 "proxied") ou supprimer l'alias, si c'en était un |
| Ligne 52: | Ligne 104: |
| 1. Nettoyer son {{{/etc/hosts}}} perso … | 1. Nettoyer son {{{/etc/hosts}}} perso… == Anciens certifs CACERT == Pour procéder aux changement de noms, il est nécessaire de supprimer le certif d'une machine présent dans la base ldap. Merci de sauvegarder les anciens certifs dans /etc/ssl/ca_cert avant de les supprimer sur le serveur en question. Procédure : 1. Aller sur un serveur crans 1. {{{cd /usr/scripts}}} et lancer ipython 1. Dans ipython, on cherche le certificat dans la base ldap, on vérifie qu'il n'est plus utilisé, on le sauvegarde, puis on le supprime {{{ In [1]: from lc_ldap import shortcuts In [2]: conn = shortcuts.lc_ldap_admin() In [3]: cert = conn.search(u"hostCert=nomdusite.crans.org", mode="rw")[0] In [4]: cert["hostCert"] # on regarde si il reste des noms utilisé Out[4]: [<class 'lc_ldap.attributs.hostCert'> : u'nomdusite.crans.org', <class 'lc_ldap.attributs.hostCert'> : u'alias.crans.org', <class 'lc_ldap.attributs.hostCert'> : u'truc.crans.org'] In [5]: with open("/home/samir/secret/nomdusite.crans.org.crt", "w") as f: # on sauvegarde le certificat f.write(cert['certificat'][0].pem()) ....: In [6]: with open("/home/samir/secret/nomdusite.crans.org.key", "w") as f: # sauvegarde la clef privée si elle existe f.write(cert["privatekey"][0]) ....: KeyError: 'privatekey' In [7]: cert["revocked"]=True # Marquer le certificat révoqué dans la base ldap (pas besoin de le révoquer en vrai si c'est une machine crans) In [8]: cert.delete() }}} 1. {{{chmod 600 /home/samir/secret/nomdusite.crans.org.key}}} 1. On vérifie qu'il n'y a pas déjà des fichiers avec le même nom {{{sudo ls -al /etc/ssl/ca_cert/}}}. 1. On déplace les sauvegardes du certificat {{{sudo mv /home/samir/secret/nomdusite.crans.org.key /home/samir/secret/nomdusite.crans.org.crt /etc/ssl/ca_cert/}}} ---- * CatégoriePagePublique * CatégorieCrans |
Autre chose que https ?
Si vous cherchez à migrer un service n'utilisant pas https, peut-être voulez-vous consulter la page CertificatsTLS
Cette page décrit le projet de centralisation des certificats Https.
Le principe est de configurer un unique serveur pour la gestion du https des nombreux sites du Crans.
Avantages :
- Un seul serveur où gérer les renouvellements de certificats
- Moins de surface d'exposition pour les nombreuses vm qui fournissent des sites web
- Possibilité de se concentrer sur les réglages https optimaux à un seul endroit
Inconvénients :
Rajoute un single point of failure (même si redondance envisageable)
- Ne résout les soucis de SSL que pour le http
- Performances ? (idem, redondance)
- Configuration moins "standard" que ce qu'on peut trouver comme tuto pour la mise en place de tout service https habituel
Actuellement, les serveurs bakdaur et frontdaur ont été créés afin de centraliser le https, notamment pour éviter les problèmes de rate-limit de la beta de letsencrypt : on génère deux certificats (hostnames-a-m.crans.org et hostnames-n-z.crans.org) de temps en temps, qui contient tous les noms de domaine (maximum de 100 noms par certificats), plutôt que pleins de petits certificats. Les rate limit ont été bien relevés, notamment, les limites pour les nouveaux certificats et pour les renouvellements sont disjointes. Il n'est donc plus nécessaire de générer un certificat avec tous les noms. Du coup, les certificats générés ici contiennent seulement les noms pointant vers proxy.crans.org.
Les deux serveurs se partagent l'adresse IP liée à proxy.crans.org. En fonctionnement normal, bakdaur possède l'ip et reste en fonction. En cas de souci, frontdaur prend la main grâce à Keepalived. Ce deuxième serveur est aussi utile pour tester le déploiement d'une nouvelle configuration nginx, avant de l'appliquer pour tout le monde.
Un schéma de principe résume la situation, avec deux alternatives possibles (fichiers statiques desservis par bakdaur ou le serveur initial).
Ticket phabricator: https://phabricator.crans.org/T9
Let's encrypt
La génération et le renouvellement des certificats se fait avec certbot.
Pour réaliser un challenge HTTP-01 sans couper NGINX qui écoute déjà sur les ports 80/443, on utilise le plugin python3-certbot-nginx.
Générer les macro certificats
Pour le moment, la génération des certificats est a faire sur bakdaur. Elle requiert les droits nounou.
La configuration des certificats à générer est créée automatiquement par bcfg2 dans /etc/letsencrypt/conf.d/. Il suffit alors de charger la nouvelle configuration dans certbot pour mettre à jour un certificat.
Quand les certificats sont générés, on les copie sur frontdaur en lançant le script /usr/scripts/utils/letsencrypt/sync-certificates.
Ci-dessous, la procédure étape par étape :
Se connecter sur bakdaur.
Lancer un run de bcfg2 pour mettre à jour la configuration des certificats avec tous les noms de domaines sudo bcfg2 -I -q.
Lancer les commandes suivantes pour générer les macro certificats pour crans.org, crans.fr, crans.eu et crans.ens-cachan.fr :
sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.org.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.org.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.fr.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.fr.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-a-m.crans.eu.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/hostnames-n-z.crans.eu.ini certonly sudo certbot --config /etc/letsencrypt/conf.d/crans.ens-cachan.fr.ini certonly
Lancer /usr/scripts/utils/letsencrypt/sync-certificates pour copier les certificats nouvellement générés sur frontdaur.
Lancer sudo service nginx reload sur frontdaur et bakdaur pour que nginx prenne en compte les certificats nouvellement générés.
Renouvellement des certificats
Manuellement
Appliquer exactement la même procédure que pour générer les certificats. Que des noms aient été ajoutés ou supprimés au certificat n'est plus important depuis l'ajout de l'option cert-name dans les fichiers de configurations.
Frontdaur ou Bakdaur
Un moyen simple de savoir lequel des deux serveurs est actuellement utilisé comme proxy est d'aller à l'adresse https://nomdusite.crans.org/.proxy-name/hostname.txt.
Patte adh
Une fois le serveur proxifié, il n'est normalement plus nécessaire de lui laisser une patte sur le réseau adh. Si l'on souhaite toutefois le faire, la convention consiste à suffixer le nom du serveur par "-srv". Ainsi "discourse.crans.org" devient "discourse-srv.crans.org". On indiquera aussi que le serveur est proxyfié dans bcfg2 à l'aide du groupe "proxied".
Proxification d'un nouveau site
On suppose que l'on dispose d'un site web sur serveur du même nom, que l'on nommera "monsiteweb". On suppose que l'on se trouve en fonctionnement normal, c'est-à-dire proxy.crans.org est géré par bakdaur et que nous pouvons donc réaliser nos tests sur frontdaur.
Les certificats sur frontdaur et bakdaur ne contiennent plus tous les nom de serveur crans, aussi, il sera nécessaire de renouveler le bon certificat une fois "monsiteweb" ajouté a la configuration.
- Aller sur le serveur de "monsiteweb"
Configurer nginx pour délivrer le site web en http (clair) en écoutant uniquement sur l'interface adm du serveur (listen monsiteweb.adm.crans.org:80)
- Ajouter dans le contexte server {} les lignes suivantes pour récupérer l'ip réelle des clients et non celle du proxy
set_real_ip_from 10.231.136.0/24; set_real_ip_from 2a01:240:fe3d:c804::/64; real_ip_header P-Real-Ip;
Ou ceci dans le VirtualHost si apache2 httpd est utilisé après s'être assuré que le module remoteip est activé.
RemoteIPHeader P-Real-Ip RemoteIPInternalProxy 10.231.136.0/24 RemoteIPInternalProxy 2a01:240:fe3d:c804::/64
- On laissera (pour le moment), en parallèle, l'écoute sur l'interface publique avec https activé
La génération du site proxy par bcfg2 avec le nouvel alias est automatique à partir du nouvel alias de la machine, il est cependant nécessaire de la faire à la main la première fois, dans /bcfg2/Python/etc/nginx/sites-available/proxy
Appliquer bcfg2 sur frontdaur et rechager nginx
Sur son ordinateur, forcer l'utilisation de frontdaur pour l'affichage de "monsiteweb.crans.org", via l'ajout d'une ligne "138.231.136.144 monsiteweb.crans.org" dans le /etc/hosts (138.231.136.144 étant l'ip de frontdaur.crans.org)
- Tester le fonctionnement de "monsiteweb.crans.org" sur son ordinateur (bien vérifier qu'il s'agit bien de frontdaur avec le certificat LE, et non du site habituel)
Si tout s'est bien passé, on applique bcfg2 sur backdaur
- On renomme la patte publique de "monsiteweb.crans.org" (renommer en "monsiteweb-srv.crans.org" et ajouter au groupe bcfg2 "proxied") ou supprimer l'alias, si c'en était un
- Rajouter en même temps "monsiteweb.crans.org" en tant qu'alias du pseudo-serveur "proxy.crans.org"
- Lorsque les DNS auront fini de se propager, les utilisateurs verront le nouveau certificat LE via proxy.crans.org (backdaur/frontdaur)
Nettoyer son /etc/hosts perso…
Anciens certifs CACERT
Pour procéder aux changement de noms, il est nécessaire de supprimer le certif d'une machine présent dans la base ldap.
Merci de sauvegarder les anciens certifs dans /etc/ssl/ca_cert avant de les supprimer sur le serveur en question.
Procédure :
- Aller sur un serveur crans
cd /usr/scripts et lancer ipython
- Dans ipython, on cherche le certificat dans la base ldap, on vérifie qu'il n'est plus utilisé, on le sauvegarde, puis on le supprime
In [1]: from lc_ldap import shortcuts In [2]: conn = shortcuts.lc_ldap_admin() In [3]: cert = conn.search(u"hostCert=nomdusite.crans.org", mode="rw")[0] In [4]: cert["hostCert"] # on regarde si il reste des noms utilisé Out[4]: [<class 'lc_ldap.attributs.hostCert'> : u'nomdusite.crans.org', <class 'lc_ldap.attributs.hostCert'> : u'alias.crans.org', <class 'lc_ldap.attributs.hostCert'> : u'truc.crans.org'] In [5]: with open("/home/samir/secret/nomdusite.crans.org.crt", "w") as f: # on sauvegarde le certificat f.write(cert['certificat'][0].pem()) ....: In [6]: with open("/home/samir/secret/nomdusite.crans.org.key", "w") as f: # sauvegarde la clef privée si elle existe f.write(cert["privatekey"][0]) ....: KeyError: 'privatekey' In [7]: cert["revocked"]=True # Marquer le certificat révoqué dans la base ldap (pas besoin de le révoquer en vrai si c'est une machine crans) In [8]: cert.delete() chmod 600 /home/samir/secret/nomdusite.crans.org.key
On vérifie qu'il n'y a pas déjà des fichiers avec le même nom sudo ls -al /etc/ssl/ca_cert/.
On déplace les sauvegardes du certificat sudo mv /home/samir/secret/nomdusite.crans.org.key /home/samir/secret/nomdusite.crans.org.crt /etc/ssl/ca_cert/