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 webs
 * 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 [[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.

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).

Ticket phabricator: https://phabricator.crans.org/T9

== Let's encrypt ==
=== 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;
        }
}}}

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}}}).

== 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}}}.
 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 …

== 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.

== Avancement ==

=== 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.