Certificats TLS

La gestion des certificats diffère fortement entre l’infrastructure à base de Docker sur aegir et l’infrastructure kubernetes sur Kity.

Gestion des certificats sur Kity

Le TLS sur Kity est intégralement géré par traefik en tant qu’IngressController : traefik lit les objets Secret référencés dans la définition des Ingress :

kind: Ingress
# [...]
spec:
  rules:
    - host: [...]
  tls:
    - hosts:
        - my.hostname.tld
      secretName: secret-ingress-myhostname

Plutôt que de générer et déposer manuellement des certificats dans des objets Secret, un gestionnaire de certificats CertManager est déployé et détecte automatiquement les certificats grâce à une annotation sur les Ingress, puis les génère grâce au fournisseur Let’s Encrypt.

kind: Ingress
# [...]
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-http

Deux versions de l’annotation sont configurées :

letsencrypt-http, pour tous domaines dont le DNS pointe bien vers l’Ingress Controller de Kity, et qui utilise un challenge ACME http-01 ;
letsencrypt-dns particulièrement pour les wildcard, le DNS devant être hébergé chez TeDomum et qui utilise le challenge ACME dns-01 en interagissant directement avec l’API d’administration DNS.

Supervision des certificats sur Kity

Un tableau de bord et une alerte est en place surveiller ceux-ci.

Gestion des certificats sur aegir

Le TLS sur aegir est géré par traefik en tant que reverse proxy général. Les certificats sont générés automatiquement par traefik également sur la base des déclarations de reverse proxy.

services:
  myservice:
    image: [...]
    labels:
      - traefik.enable=true
      - traefik.port=1234
      - traefik.frontend.rule=Host:my.hostname.tld

Ces labels configurés sont conformes au standard traefik v1, qui est encore employé sur aegir. Hors traefik v1 est pauvre dans sa configuration Let’s Encrypt : il ne supporte qu’un seul mode de challenge à la fois (http-01, tls-01 ou dns-01) appliqué pour tous les domaines référencés. La migration vers traefik v2 a été envisagée mais elle est trop chère pour un serveur que l’on souhaite maintenir à moindre coût en attendant son remplacement.

Hors http-01 et dns-01 ne sont pas applicables pour les domaines wildcard et génèrent en prime des challenges pour chaque domaine en tedomum.net (soit plus de 30 domaines), approchant les rate limits de production de Let’s Encrypt. Par ailleurs, dns-01 requiert que le domaine soit hébergé par TeDomum car il ne supporte qu’un fournisseur DNS à la fois, configuré sur les API de TeDomum.

Il faut donc, pour générer tous les certificats sur aegir, à la fois du tls-01 (http-01 fonctionnerait aussi) et du dns-01, donc alterner la configuration traefik entre un mode et l’autre.

Pour basculer de mode, on commente tantôt la première ligne de configuration, tantôt les deux suivantes :

#[acme.tlsChallenge]

[acme.dnsChallenge]
provider = "pdns"

La procédure est simplement :

Changer les lignes commentées
Restart par docker-compose restart traefik
Vérifier le bon fonctionnement général

Cas particulier de Gitlab Pages

Gitlab pages est hébergé sur aegir avec le reste de Gitlab Omnibus. Il n’utilise toutefois pas le reverse proxy traefik mais expose directement sont nginx sur le port 443 sur une IP dédiée.

Le certificat est généré par ŧraefik via une configuration statique :

[[acme.domains]]
main = "*.tedomum.org"
sans = ["tedomum.org"]

On extrait régulièrement le certificat du dépôt traefik pour l’injecter dans la configuration Gitlab :

cat /srv/core/front/certs/acme.json \
| jq '.Certificates[]|select(.Domain.Main|contains("*.tedomum.org"))|.Certificate|@base64d' -r \
> /srv/apps/forge/conf/ssl/tedomum.org.crt

Vérifier l’état d’un certificat

Commande pour vérifier les dates de certificats :

openssl s_client -connect tedomum.net:443 2>/dev/null | openssl x509 -noout -enddate