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 web
• 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 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 rate limit on été bien relevé, notamment, la limites pour les nouveau certificat et pour les renouvellement sont disjointe. Il n'est donc plus nécessaire de générer un certificat avec tous les noms. Du coup, les certificat généré ici contiennent seulement les noms pointant vers proxy.crans.org.

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.

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 requiert 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 serveur. 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.

2. Lancer un run de bcfg2 pour mettre à jour la configuration des certificats avec tous les noms de domaines sudo bcfg2 -I -q.

3. Lancer /usr/scripts/utils/letsencrypt/enable-challenge-proxy pour activer la redirection de /.well-known/acme-challenge vers bakdaur.

4. Lancer les commandes suivantes pour générer les macro certificats pour crans.org, crans.fr, crans.eu et crans.ens-cachan.fr :

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

6. Lancer /usr/scripts/utils/letsencrypt/disable-challenge-proxy pour désactiver la redirection de /.well-known/acme-challenge vers bakdaur.

7. Lancer /usr/scripts/utils/letsencrypt/sync-certificates pour copier les certificats nouvellement générés sur frontdaur

8. 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. Que des noms aient été ajoutés ou supprimés au certificat n'est plus important depuis l'ajout de l'option cert-name dans les fichiers de configurations.

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.

Les certificats sur frontdaur et bakdaur ne contiennent plus tous les nom de serveur crans, aussi, il sera nécessaire de renouveler le bon certificat une fois "monsiteweb" ajouté a la configuration.

1. Aller sur le serveur de "monsiteweb"

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

3. 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;

   Ou ceci dans le VirtualHost si apache2 httpd est utilisé

   • RemoteIPHeader P-Real-Ip 
     RemoteIPInternalProxy 10.231.136.0/24
     RemoteIPInternalProxy 2a01:240:fe3d:c804::/64

4. On laissera (pour le moment), en parallèle, l'écoute sur l'interface publique avec https activé

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

6. Appliquer bcfg2 sur frontdaur et rechager nginx

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

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

9. Si tout s'est bien passé, on applique bcfg2 sur backdaur

10. 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
11. Rajouter en même temps "monsiteweb.crans.org" en tant qu'alias du pseudo-serveur "proxy.crans.org"
12. Lorsque les DNS auront fini de se propager, les utilisateurs verront le nouveau certificat LE via proxy.crans.org (backdaur/frontdaur)

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

2. cd /usr/scripts et lancer ipython

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

4. chmod 600 /home/samir/secret/nomdusite.crans.org.key

5. 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/.

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