#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]] }}} 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 [[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}}}. 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. [[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). 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 : 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 }}} 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. === 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. 1. Aller sur le serveur de "monsiteweb" 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 }}} 1. On laissera (pour le moment), en parallèle, l'écoute sur l'interface publique avec https activé 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) 1. 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) 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 1. Rajouter en même temps "monsiteweb.crans.org" en tant qu'alias du pseudo-serveur "proxy.crans.org" 1. Lorsque les DNS auront fini de se propager, les utilisateurs verront le nouveau certificat LE via proxy.crans.org (backdaur/frontdaur) 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]: [ : u'nomdusite.crans.org', : u'alias.crans.org', : 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