#format wiki
#language fr
#acl +All:read
{{{#!wiki tip
'''Autre chose que https ?'''

Si vous chercher à migrer un services n'utilisant pas `https`, peut être voudriez cous 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 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 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 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 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 ==
=== Mode webroot ===
On évite de couper nginx pour renouveler/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;
        }
}}}
Le sous-dossier {{{acme-challenge}}} est utilisé par LE pour placer les challenges nécessaires à l'obtention du certificat.

=== Générer les macro certificats ===
Pour le moment, la génération des certificats est a faire sur {{{bakdaur}}}. Elle requière les droits nounou.

Pour générer les certificats, il faut que toutes les requêtes {{{http://monsite.crans.org/.well-known/acme-challenge}}} soient dirigées vers le même serveurs. Cela est effectué, temporairement lors de la génération des certificats, par le pare-feu sur {{{odlyd}}}. Celui-ci redirige tout le trafic destiné aux serveurs crans sur le port 80 vers le port 81 de {{{bakdaur}}} ou {{{frontdaur}}}. Sur ce port 81 écoute un proxy qui sert {{{/.well-known/acme-challenge}}} localement, et proxifie le reste vers sa destination originale. Grâce à cela, il n'y a normalement aucun downtime des sites originaux durant la génération des certificats.

Pour activer la redirection, lancer {{{/usr/scripts/utils/letsencrypt/enable-challenge-proxy}}}, pour la désactiver une fois les certificats générés, lancer {{{/usr/scripts/utils/letsencrypt/disable-challenge-proxy}}}.

La configuration des certificats à générer est créée automatiquement par bcfg2 dans {{{/etc/letsencrypt/conf.d/}}}

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 {{{/usr/scripts/utils/letsencrypt/enable-challenge-proxy}}} pour activer la redirection de {{{/.well-known/acme-challenge}}} vers {{{bakdaur}}}.
 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/disable-challenge-proxy}}} pour désactiver la redirection de {{{/.well-known/acme-challenge}}} vers {{{bakdaur}}}.
 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. C'est là également la marche à suivre si on veut ajouter un nom aux certificats. Pour retirer un nom au certificat, le client ne sais pas encore le faire, il faut donc supprimer les fichiers liés aux certificats dans `/etc/letsencrypt/live`, `/etc/letsencrypt/archive` et `/etc/letsencrypt/renewal`, sinon, le client crée un doublon dont le nom se termine par -0001.

Dans le doute, partir du principe que bcfg2 a supprimé des noms du certificat. On lance donc :

{{{
# cd /etc/letsencrypt/
# mkdir old.N # avec N le plus petit entier naturel tel que old.N n'existe pas
# mv live/ archive/ renewal/ old.N/
}}}
puis suivre la procédure de création.

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

 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;
}}}
 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]:
[<class 'lc_ldap.attributs.hostCert'> : u'nomdusite.crans.org',
 <class 'lc_ldap.attributs.hostCert'> : u'alias.crans.org',
 <class 'lc_ldap.attributs.hostCert'> : 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/}}}

== 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 et munin : sur fy, par le proxy
 * Discourse : cas particulier, dans la liste gérée à la main, possède son propre site sur les proxy.
 * o2 : http entre proxy et intranet.adm, redirection depuis les anciens alias sur les proxy
 * fy : en place pour munin, icingaweb2 et weathermap, redirection depuis les proxy vers munin.adm, icinga2.adm et weathermap.adm.
 * owncloud : passage vers owncloud-srv, et owncloud.adm par les proxy. Subtilité avec le cas, ne pas oublier de fastcgi_param SERVER_PORT 443; dans le site owncloud, sinon le cas chibre
 * niomniom : transfert de wifi, wiki, et autostatus sur proxy (les ndd), et l'alias wikipedia.crans.org

----
 * CatégoriePagePublique
 * CatégorieCrans