alpinux.cedrica5l/alpinux-owni
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Deux mécanismes de certificats coexistent, et rien ne le documente #4

New issue
Closed
opened 2026-09-27 09:10:30 +02:00 by Cédric A5L · 1 comment
Cédric A5L commented 2026-09-27 09:10:30 +02:00
Owner
Copy link

Deux mécanismes délivrent les certificats TLS de la machine, et rien ne le
dit :

Service Mécanisme Expire dans
messagerie.alpinux.org acme.sh (/root/.acme.sh/messagerie.alpinux.org_ecc) 85 jours
alpinux.org certbot (/etc/letsencrypt/live/) 49 jours
wiki.alpinux.org certbot 49 jours
gitea.alpinux.org certbot 49 jours
alpid.alpinux.org certbot 49 jours

Les certificats d'ISPConfig atterrissent dans
/var/www/clients/client1/web21/ssl/ (…-le.crt, …-le.key), ceux de certbot
dans /etc/letsencrypt/live/.

Pourquoi cela compte

Rien n'est cassé aujourd'hui : tous les certificats sont valides et aucun
n'expire avant sept semaines. Le problème est ailleurs.

  • Deux mécanismes, deux façons de tomber en panne, et deux endroits où
    chercher quand un site passe en « connexion non sécurisée » un dimanche.
  • Chercher au mauvais endroit fait perdre du temps : quelqu'un qui
    diagnostique un certificat de la messagerie dans /etc/letsencrypt/ ne
    trouvera rien du tout, et pourra conclure qu'il n'y en a pas.
  • Le renouvellement d'acme.sh passe par ISPConfig, celui de certbot par son
    propre minuteur systemd. Vérifier que « le renouvellement automatique
    fonctionne » demande donc de vérifier deux choses.

À faire

  • Au minimum, l'écrire dans le README : quel service utilise quoi, où
    trouver le certificat, et comment se vérifie le renouvellement de chaque
    côté.
  • Éventuellement, unifier — les sites gérés par ISPConfig sur acme.sh,
    puisque c'est lui qui les crée. Mais migrer un certificat qui fonctionne
    pour faire joli n'a pas d'urgence, et un changement raté se voit tout de
    suite par les visiteurs.

Vérification utile en attendant

# Ce que voit réellement un visiteur, quel que soit le mécanisme
for d in messagerie.alpinux.org alpinux.org wiki.alpinux.org gitea.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

C'est la seule méthode qui ne dépend pas de savoir quel mécanisme est en jeu.

Deux mécanismes délivrent les certificats TLS de la machine, et rien ne le dit : | Service | Mécanisme | Expire dans | |---|---|---| | `messagerie.alpinux.org` | **acme.sh** (`/root/.acme.sh/messagerie.alpinux.org_ecc`) | 85 jours | | `alpinux.org` | certbot (`/etc/letsencrypt/live/`) | 49 jours | | `wiki.alpinux.org` | certbot | 49 jours | | `gitea.alpinux.org` | certbot | 49 jours | | `alpid.alpinux.org` | certbot | 49 jours | Les certificats d'ISPConfig atterrissent dans `/var/www/clients/client1/web21/ssl/` (`…-le.crt`, `…-le.key`), ceux de certbot dans `/etc/letsencrypt/live/`. ## Pourquoi cela compte Rien n'est cassé aujourd'hui : tous les certificats sont valides et aucun n'expire avant sept semaines. Le problème est ailleurs. - **Deux mécanismes, deux façons de tomber en panne**, et deux endroits où chercher quand un site passe en « connexion non sécurisée » un dimanche. - **Chercher au mauvais endroit fait perdre du temps** : quelqu'un qui diagnostique un certificat de la messagerie dans `/etc/letsencrypt/` ne trouvera rien du tout, et pourra conclure qu'il n'y en a pas. - Le renouvellement d'acme.sh passe par ISPConfig, celui de certbot par son propre minuteur systemd. Vérifier que « le renouvellement automatique fonctionne » demande donc de vérifier deux choses. ## À faire - **Au minimum**, l'écrire dans le README : quel service utilise quoi, où trouver le certificat, et comment se vérifie le renouvellement de chaque côté. - **Éventuellement**, unifier — les sites gérés par ISPConfig sur acme.sh, puisque c'est lui qui les crée. Mais migrer un certificat qui fonctionne pour faire joli n'a pas d'urgence, et un changement raté se voit tout de suite par les visiteurs. ## Vérification utile en attendant ```sh # Ce que voit réellement un visiteur, quel que soit le mécanisme for d in messagerie.alpinux.org alpinux.org wiki.alpinux.org gitea.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 ``` C'est la seule méthode qui ne dépend pas de savoir quel mécanisme est en jeu.
Cédric A5L commented 2026-09-27 09:54:27 +02:00
Author
Owner
Copy link

Correction : le diagnostic de ce ticket était largement faux

J'ai écrit que « deux mécanismes coexistent et que rien ne le documente ».
C'est inexact sur les deux points, et la réalité est meilleure.

Les deux mécanismes sont déjà réconciliés, par
/usr/local/sbin/owni-certs-sync.sh. Son en-tête documente précisément le
piège — ISPConfig ne rafraîchit sa copie dans
/var/www/clients/<client>/<web>/ssl/ que lorsqu'il crée le certificat,
si bien qu'un renouvellement par certbot passe inaperçu et que le vhost
continue de servir l'ancien jusqu'à expiration. Le script cite même
l'incident : HTTPS cassé sur static et portail le 1er août 2026, constaté
le 5 septembre.

Le dispositif est complet : un hook
/etc/letsencrypt/renewal-hooks/deploy/ispconfig-cert.sh pour le cas
nominal, ce script en filet de sécurité chaque nuit à 4 h 20, un mode audit,
et un seuil d'alerte à 21 jours.

Sur le certificat multi-domaines : celui d'alpid.alpinux.org couvre dix
noms (alpid, alpinux.org, autoconfig, cloud, dolibarr, gitea, installparty,
owni, wiki, www). Dix sur les cent autorisés par Let's Encrypt : le nombre
n'est pas le problème. Le couplage l'est — un domaine dont la validation
échoue emporte les neuf autres.

Et il y a un doublon que l'audit révèle : neuf certificats ISPConfig existent
et ne servent à rien, chaque site étant en réalité couvert par le SAN.

inutilisé  wiki.alpinux.org — .../web2/ssl/wiki.alpinux.org-le.crt
inutilisé  gitea.alpinux.org — .../web4/ssl/gitea.alpinux.org-le.crt
inutilisé  alpid.alpinux.org — .../web5/ssl/alpid.alpinux.org-le.crt
…

C'est ce doublon qu'il faudrait trancher un jour, pas le nombre de noms. Sans
urgence : rien n'est cassé de ce fait.

Ce qui reste vrai, et qui est le vrai sujet

L'alerte n'atteint personne. Le script signale cloud.alpinux.org depuis
54 jours, et personne ne l'a vu — voir #5 pour la panne, et #6 pour la cause.

Ce ticket est donc fermé : il décrivait un désordre qui n'existe pas.

## Correction : le diagnostic de ce ticket était largement faux J'ai écrit que « deux mécanismes coexistent et que rien ne le documente ». C'est inexact sur les deux points, et la réalité est meilleure. **Les deux mécanismes sont déjà réconciliés**, par `/usr/local/sbin/owni-certs-sync.sh`. Son en-tête documente précisément le piège — ISPConfig ne rafraîchit sa copie dans `/var/www/clients/<client>/<web>/ssl/` que lorsqu'il **crée** le certificat, si bien qu'un renouvellement par certbot passe inaperçu et que le vhost continue de servir l'ancien jusqu'à expiration. Le script cite même l'incident : HTTPS cassé sur `static` et `portail` le 1er août 2026, constaté le 5 septembre. Le dispositif est complet : un hook `/etc/letsencrypt/renewal-hooks/deploy/ispconfig-cert.sh` pour le cas nominal, ce script en filet de sécurité chaque nuit à 4 h 20, un mode audit, et un seuil d'alerte à 21 jours. **Sur le certificat multi-domaines** : celui d'`alpid.alpinux.org` couvre dix noms (alpid, alpinux.org, autoconfig, cloud, dolibarr, gitea, installparty, owni, wiki, www). Dix sur les cent autorisés par Let's Encrypt : le nombre n'est pas le problème. Le **couplage** l'est — un domaine dont la validation échoue emporte les neuf autres. Et il y a un doublon que l'audit révèle : **neuf certificats ISPConfig existent et ne servent à rien**, chaque site étant en réalité couvert par le SAN. ``` inutilisé wiki.alpinux.org — .../web2/ssl/wiki.alpinux.org-le.crt inutilisé gitea.alpinux.org — .../web4/ssl/gitea.alpinux.org-le.crt inutilisé alpid.alpinux.org — .../web5/ssl/alpid.alpinux.org-le.crt … ``` C'est ce doublon qu'il faudrait trancher un jour, pas le nombre de noms. Sans urgence : rien n'est cassé de ce fait. ## Ce qui reste vrai, et qui est le vrai sujet **L'alerte n'atteint personne.** Le script signale `cloud.alpinux.org` depuis 54 jours, et personne ne l'a vu — voir #5 pour la panne, et #6 pour la cause. Ce ticket est donc fermé : il décrivait un désordre qui n'existe pas.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: alpinux.cedrica5l/alpinux-owni#4
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?