|
Taille: 4341
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". 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. 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. 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 peut renommer le patte publique de "monsiteweb" (renommer en "monsiteweb-srv" 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) |
=== 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 : 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. ---- * 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.