alpinux-owni/docs/certificats.md

Certificats TLS sur owni

État relevé le 27/09/2026. Deux mécanismes coexistent, et ce n'est pas un désordre : c'est une histoire. Ce document dit lequel gère quoi, où chercher quand un site passe en « connexion non sécurisée », et ce qui a déjà cassé.

Qui gère quoi

certbot — un certificat multi-domaines pour huit sites

/etc/letsencrypt/live/alpid.alpinux.org/ porte un seul certificat couvrant dix noms :

alpid.alpinux.org      dolibarr.alpinux.org    owni.alpinux.org
alpinux.org            gitea.alpinux.org       wiki.alpinux.org
autoconfig.alpinux.org installparty.alpinux.org www.alpinux.org
cloud.alpinux.org

Huit vhosts le servent directement. Renouvellement : certbot renew chaque nuit à 3 h 00, par cronwrap (donc visible sur admin.alpinux.org).

Dix noms sur les cent autorisés : le nombre n'est pas un problème, le couplage l'est. Un seul domaine dont le DNS casse ou dont la validation échoue empêche le renouvellement des neuf autres. Et un nom couvert par un SAN devient un cas particulier que les outils traitent mal — voir l'incident cloud plus bas.

ISPConfig et acme.sh — un certificat par site

ISPConfig émet par acme.sh (/root/.acme.sh/<domaine>_ecc/) et dépose une copie dans /var/www/clients/<client>/<web>/ssl/<domaine>-le.crt. C'est cette copie que le vhost lit, jamais l'original.

Concernés : admin, messagerie, portail, static.

Le piège, et il a déjà mordu deux fois

ISPConfig ne rafraîchit sa copie que lorsqu'il crée le certificat. Un renouvellement par certbot passe inaperçu : le vhost continue de servir l'ancien fichier jusqu'à son expiration, puis le site tombe. Re-sauvegarder le site dans l'interface ne suffit pas à déclencher la copie.

Quand	Quoi	Vu le
1er août 2026	static et portail perdent leur HTTPS	5 septembre
4 août 2026	cloud perd son HTTPS	27 septembre

Cinq semaines, puis sept. C'est le délai qu'il faut pour que quelqu'un s'aperçoive qu'un site ne répond plus.

Le dispositif qui l'évite aujourd'hui

1. Le hook /etc/letsencrypt/renewal-hooks/deploy/ispconfig-cert.sh s'exécute après chaque renouvellement certbot. Il itère sur $RENEWED_DOMAINS — tous les noms du certificat, SAN compris —, cherche */ssl/${domain}-le.crt sous /var/www/clients et le met à jour. C'est le cas nominal.
2. Le filet /usr/local/sbin/owni-certs-sync.sh, chaque nuit à 4 h 20, rattrape ce que le hook n'a pas traité : hook absent lors d'un renouvellement passé, copie écrasée par ISPConfig, certificat posé à la main. Mode audit par défaut, --fix pour corriger, alerte à 21 jours.
3. La surveillance : depuis le 27/09/2026 ce script passe par cronwrap, donc son état remonte sur admin.alpinux.org. Auparavant il alertait par MAILTO=root, c'est-à-dire nulle part — l'expiration de cloud a été signalée chaque nuit pendant 54 jours sans que personne la voie.

Retenir de cette histoire : une alerte qui n'atteint personne n'est pas une alerte. Le script fonctionnait parfaitement ; c'est sa sortie qui se perdait.

Diagnostiquer

La seule méthode qui ne dépend pas du mécanisme

Ce que voit un visiteur, quel que soit l'outil qui a émis le certificat :

for d in messagerie.alpinux.org alpinux.org wiki.alpinux.org \
         gitea.alpinux.org cloud.alpinux.org; do
  fin=$(echo | openssl s_client -servername $d -connect $d:443 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  echo "$d : $(( ($(date -d "$fin" +%s) - $(date +%s)) / 86400 )) jours"
done

Un echo | openssl s_client qui ne rend rien = TLS cassé, donc site inaccessible en HTTPS.

L'audit complet, sur le serveur

sudo /usr/local/sbin/owni-certs-sync.sh          # audit, n'écrit rien
sudo /usr/local/sbin/owni-certs-sync.sh --fix    # corrige ce qu'il peut

Il rend 0 si tout est cohérent, 1 s'il subsiste une anomalie. Sa sortie distingue :

• ok — à jour ;
• ORPHELIN (majuscules) — expiré, c'est une panne ;
• orphelin (minuscules) — inconnu de certbot mais valide, simple avertissement ;
• inutilisé — un certificat existe et aucun service ne le lit.

Quel certificat un vhost lit-il vraiment

for f in /etc/apache2/sites-enabled/*.vhost; do
  cert=$(sudo awk '/SSLCertificateFile/ {print $2; exit}' "$f")
  [ -n "$cert" ] && printf "%-34s %s\n" "$(basename "$f")" "$cert"
done

Ce que couvre un certificat multi-domaines

sudo openssl x509 -noout -text -in /etc/letsencrypt/live/alpid.alpinux.org/fullchain.pem \
  | grep -A1 "Subject Alternative Name"

Réparer un site dont le certificat a expiré

Cas rencontré le 27/09/2026 avec cloud.alpinux.org.

1. Établir ce qui manque vraiment. Le nom est-il couvert par un certificat valide existant ? S'il est dans le SAN, il n'y a rien à émettre — seulement à recopier.

2. Recopier le certificat valide à l'emplacement que le vhost attend, en gardant l'ancien plutôt qu'en l'écrasant :

D=/var/www/clients/client1/web19/ssl
L=/etc/letsencrypt/live/alpid.alpinux.org

sudo cp -a $D/cloud.alpinux.org-le.crt $D/cloud.alpinux.org-le.crt.expire-AAAAMMJJ
sudo cp -a $D/cloud.alpinux.org-le.key $D/cloud.alpinux.org-le.key.expire-AAAAMMJJ
sudo cp $L/fullchain.pem $D/cloud.alpinux.org-le.crt
sudo cp $L/privkey.pem   $D/cloud.alpinux.org-le.key
sudo chmod 644 $D/cloud.alpinux.org-le.crt
sudo chmod 600 $D/cloud.alpinux.org-le.key

sudo apache2ctl configtest && sudo systemctl reload apache2

3. Vérifier de l'extérieur, pas seulement que la commande a rendu la main.

Une fois le fichier en place, le hook le maintiendra : il cherche */ssl/${domain}-le.crt et ne peut mettre à jour que ce qui existe. C'est pourquoi cette réparation n'est pas un pansement.

Alternative propre, si le domaine mérite son propre certificat : le réémettre depuis ISPConfig (Sites → le site → SSL → Let's Encrypt, décocher, enregistrer, recocher, enregistrer).

Ce qui reste en suspens

Neuf certificats ISPConfig ne servent à rien. Chaque site couvert par le SAN possède en plus un certificat à son nom, généré et jamais lu :

inutilisé  wiki.alpinux.org, gitea.alpinux.org, alpid.alpinux.org,
           dolibarr.alpinux.org, installparty.alpinux.org,
           autoconfig.alpinux.org, alpinux.org, owni.alpinux.org, cloud…

Rien n'est cassé de ce fait, et les supprimer demanderait de vérifier un par un qu'aucun service — Postfix, Dovecot, pure-ftpd — ne les lit. Le script les signale précisément pour éviter qu'on cesse de mettre à jour un fichier qui sert ailleurs.

owni-certs-sync.sh raisonne par nom de dossier, pas par SAN. Il cherche /etc/letsencrypt/live/<domaine>/ et classe « orphelin » tout nom qui n'en a pas — même couvert par le SAN d'un autre. C'est pourquoi il a su signaler l'expiration de cloud sans pouvoir la réparer. Lui apprendre à lire les SAN le rendrait autonome sur ce cas.

Le script n'est pas versionné

/usr/local/sbin/owni-certs-sync.sh et le hook n'existent que sur la machine. Choix assumé : ce sont des rustines autour d'un comportement d'ISPConfig, et les versionner reviendrait à les pérenniser. Mais cela veut dire qu'un serveur reconstruit les perdra, avec la connaissance qu'ils portent — d'où ce document, qui doit suffire à les réécrire.