|
Taille: 1929
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, le serveur "bakdaur" a été créé 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: |
| [[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 23: | 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/acme-challenge { alias /usr/share/nginx/html/.well-known/acme-challenge; } }}} |
|
| Ligne 31: | Ligne 35: |
| == 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". |
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 : 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.