{{indexmenu_n>50}}
# Générer les certificats pour un service non-web

<bootnote critical>Cette technique est obsolète maintenant que Traefik supporte les terminaisons TLS pour les services non-web, voir : https://gitlab.utc.fr/picasoft/projets/transverse/-/issues/13</bootnote>

## Préambule

Il existe des services auxquels on accès pas par le protocole HTTPS, mais qui ont tout de même besoin de communiquer de manière sécurisée (avec TLS).

<bootnote>Dans la plupart des cas, un certificat auto-signé ne suffit pas. Par exemple, notre serveur mail utilise TLS pour sécuriser ses échanges SMTP, et doit fournir un certificat valide (*i.e.* fourni par une autorité de certification racine).</bootnote>

C'est aussi le cas pour LDAP : on utilise le protocole LDAPS, qui requiert un certificat pour authentifier et chiffrer les communications.

<bootnote>Aujourd'hui, la manière la plus facile de générer un certificat est d'utiliser [Let's Encrypt](https://letsencrypt.org/). On ne détaille pas le fonctionnement, mais l'idée est de prouver qu'on est bien en contrôle du nom de domaine que l'on prétend avoir. Pour ce faire, Let's Encrypt propose des challenges, comme mettre en ligne un fichier avec un contenu précis, ou modifier un enregistrement DNS.</bootnote>

<bootnote question>Pourquoi ne pas utiliser un outil comme `certbot` ?</bootnote>

Ce serait possible, mais pourquoi ne pas utiliser Traefik directement ? En effet, Traefik gère déjà automatiquement la création et le renouvellement des certificats avec Let's Encrypt. Par contre, il est plutôt orienté web, et fait difficilement proxy avec des services non-web.

<bootnote question>Comment utiliser les certificats générés par Traefik directement dans les services non-web ?</bootnote>

## TLS Certs Monitor

TLSCertsMonitor est un outil développé par Picasoft avec un but simple : extraire les certificats générés par Traefik, et les mettre à disposition dans des fichiers qui pourront être utilisés par le service concerné. L'outil se charge aussi de mettre à jour les certificats en cas de changement, et de redémarrer le service si nécessaire.

<bootnote web>La documentation technique est répartie à deux endroits :
   * [TLSCertsMonitor chez Picasoft](https://gitlab.utc.fr/picasoft/projets/services/tls-certs-monitor)
   * [Tutoriel technique pour l'utilisation de TLSCertsMonitor](https://gitlab.utc.fr/picasoft/projets/tls-cert-monitor)
</bootnote>

Prenons tout de même un exemple complet pour faciliter la lecture de la documentation.

```yaml
services:
  non-web:
    labels:
      traefik.http.routers.<container-name>.rule: Host(`non-web.picasoft.net`)
      traefik.enable: true
      tls-certs-monitor.enable: true
      tls-certs-monitor.action: kill:SIGUSR1
      tls-certs-monitor.owner: 103
```

On active Traefik sur ce service, **uniquement** pour le forcer à générer les certificats pour `non-web.picasoft.net`. En revanche, Traefik ne routera rien lui-même (on ne lui a pas indiqué d'entrypoint, ni de port...) Par ailleurs, on suppose que ce service est bindé sur un port de l'hôte.

Ensuite, on active la prise en charge de ce service par TLSCertsMonitor, et on lui dit quoi faire. À chaque renouvellement de certificat par Traefik, l'outil va extraire le certificat, la clé, etc, et les écrire dans le fichier `/DATA/docker/certs/non-web.picasoft.net`, avec le propriétaire d'UID `103` (le même UID que celui qui fait tourner le service ; inutile si `root`).

<bootnote>`/DATA/docker/certs` est choisi une bonne fois pour toutes dans notre configuration de TLSCertsMonitor, et un sous-dossier est créé automatiquement en fonction de l'URL.</bootnote>

Ensuite, dès qu'un nouveau certificat sera détecté, un signal `USR1` sera envoyé au conteneur.

<bootnote>Le choix du signal dépend du service : ici, on a choisi `USR1` parce que le service en question recharge sa configuration TLS quand il reçoit un signal `USR1`.</bootnote>

Ne pas hésiter à se référer à la documentation complète pour voir plus d'options.