|
Taille: 5819
Commentaire:
|
← Version 54 à la date du 2020-05-04 14:40:25 ⇥
Taille: 3104
Commentaire: Wildcards are so wild!
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Cette page décrit le projet de centralisation des certificats Https. | #format wiki #language fr #acl +All:read {{{#!wiki tip '''Autre chose que https ?''' |
| Ligne 3: | Ligne 7: |
| Le principe est de configurer un unique serveur pour la gestion du https des nombreux sites du Crans. | Si vous cherchez à migrer un service n'utilisant pas `https`, peut-être voulez-vous consulter la page [[../CertificatsTLS|CertificatsTLS]] }}} |
| Ligne 5: | Ligne 10: |
| Avantages : * Un seul serveur où gérer les renouvellements de certificats * Moins de surface d'exposition pour les nombreuses vm qui fournissent des sites webs * Possibilité de se concentrer sur les réglages https optimaux à un seul endroit |
Le Crans utilise deux serveurs [[CransTechnique/LesServeurs/Virtuels/ServeurBakdaur | bakdaur]] (principal) et [[CransTechnique/LesServeurs/Virtuels/ServeurFrontdaur | frontdaur]] (backup) qui permettent de centraliser le traffic entrant vers les services Web. |
| Ligne 10: | Ligne 12: |
| Inconvénients : * Rajoute un single point of failure (même si redondance envisageable) |
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. Avantages : * Un seul serveur où gérer les renouvellements de certificats Let's Encrypt * Moins de surface d'exposition pour les nombreuses machines qui fournissent des sites web * Possibilité de se concentrer sur les réglages optimaux à un seul endroit * Permet de compresser le flux HTTP/1.1 vers du HTTP/2 pour les clients le supportant * Permet d'assurer une sécurité homogène sur tous les sites Crans Inconvénients : |
| Ligne 13: | Ligne 25: |
| * Performances ? (idem, redondance) * Configuration moins "standard" que ce qu'on peut trouver comme tuto pour la mise en place de tout service https habituel |
* Configuration moins « standard » que ce qu'on peut trouver comme tuto pour la mise en place de tout service https habituel |
| Ligne 16: | Ligne 27: |
| 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. | ''Legacy'' : avant on générait deux certificats (hostnames-a-m.crans.org et hostnames-n-z.crans.org) avec un challenge Let's Encrypt HTTP-01. Maintenant on a un certificat Wildcard avec un challenge DNS-01 qui permet de simplifier beaucoup la configuration. |
| Ligne 18: | Ligne 29: |
| 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. [[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 34: |
| === 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; } }}} |
|
| Ligne 33: | Ligne 35: |
| 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}}}). |
La génération et le renouvellement des certificats se fait avec {{{certbot}}}. Voir le rôle Ansible pour plus de détails, mais en gros il parle à {{{silice.crans.org}}} pour ajouter temporairement une entrée DNS et effectuer un challenge DNS-01. |
| Ligne 37: | Ligne 37: |
| == 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". |
Pour initialiser le certificat la première fois, il faut lancer certbot avec les fichiers de conf dans {{{/etc/letsencrypt/conf.d}}}. |
| Ligne 40: | Ligne 39: |
| == 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}}}. 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. 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 necessaire de la faire à la main la première fois, dans {{{/bcfg2/Python/etc/nginx/sites-available/proxy}}} 1. Appliquer bcfg2 sur {{{frontdaur}}} et reloader 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 … |
=== Renouvellement === |
| Ligne 55: | Ligne 41: |
| == Anciens certifs CACERT == | C'est automatique avec un timer Systemd ! Si ça fail, prometheus relève l'alerte. |
| Ligne 57: | Ligne 43: |
| Pour procéder aux changement de noms, il est nécessaire de supprimer le certif d'une machine présent dans la base ldap. | == Je veux du HTTPS sur mon nouveau site ! == |
| Ligne 59: | Ligne 45: |
| Merci de sauvegarder les anciens certifs dans /etc/ssl/ca_cert avant de les supprimer sur le serveur en question. | Ci-dessous, la procédure étape par étape : |
| Ligne 61: | Ligne 47: |
| == Avancement == | 1. Ajouter la règle de reverse proxy dans [[https://gitlab.crans.org/nounous/ansible/-/blob/master/network.yml#L73 | network.yml]] ; 1. Lancer ce playbook Ansible avec {{{--limit frontdaur.adm.crans.org}}} et vérifier que ça marche ; 1. Lancer ce playbook Ansible sur bakdaur ; 1. [[https://www.youtube.com/watch?v=YnopHCL1Jk8 | Danser sur place]] et profiter. |
| Ligne 63: | Ligne 52: |
| === LE déployé === * Cas : basculé sur les proxy, http entre proxy et cas-srv, écoute uniquement sur adm, pour les ndd cas.crans.org, auth.crans.org et login.crans.org , le serveur cas devient cas-srv et proxied. * Tracker : idem pour le ndd phabricator.crans.org * kenobi : idem avec pad.crans.org, zero.crans.org et pastebin.crans.org * Roundcube : http entre proxy et roundcube-srv, basculement en proxied, écoute que sur adm. * Ethercalc : http entre proxy et ethercalc-srv, basculement en proxied, écoute que sur adm. * Horde et webmail : http entre proxy et horde-srv, basculement en proxied, écoute que sur adm. * Icinga: sur fy, par le proxy * Discourse : cas particulier, dans la liste géré à la main, possède son propre site sur les proxy. |
---- * 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
Le Crans utilise deux serveurs bakdaur (principal) et frontdaur (backup) qui permettent de centraliser le traffic entrant vers les services Web.
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.
Avantages :
- Un seul serveur où gérer les renouvellements de certificats Let's Encrypt
- Moins de surface d'exposition pour les nombreuses machines qui fournissent des sites web
- Possibilité de se concentrer sur les réglages optimaux à un seul endroit
- Permet de compresser le flux HTTP/1.1 vers du HTTP/2 pour les clients le supportant
- Permet d'assurer une sécurité homogène sur tous les sites Crans
Inconvénients :
- Ne résout les soucis de SSL que pour le http
- Configuration moins « standard » que ce qu'on peut trouver comme tuto pour la mise en place de tout service https habituel
Legacy : avant on générait deux certificats (hostnames-a-m.crans.org et hostnames-n-z.crans.org) avec un challenge Let's Encrypt HTTP-01. Maintenant on a un certificat Wildcard avec un challenge DNS-01 qui permet de simplifier beaucoup la configuration.
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. Voir le rôle Ansible pour plus de détails, mais en gros il parle à silice.crans.org pour ajouter temporairement une entrée DNS et effectuer un challenge DNS-01.
Pour initialiser le certificat la première fois, il faut lancer certbot avec les fichiers de conf dans /etc/letsencrypt/conf.d.
Renouvellement
C'est automatique avec un timer Systemd ! Si ça fail, prometheus relève l'alerte.
Je veux du HTTPS sur mon nouveau site !
Ci-dessous, la procédure étape par étape :
Ajouter la règle de reverse proxy dans network.yml ;
Lancer ce playbook Ansible avec --limit frontdaur.adm.crans.org et vérifier que ça marche ;
- Lancer ce playbook Ansible sur bakdaur ;
Danser sur place et profiter.