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

cloud.alpinux.org : HTTPS hors service depuis le 4 août #5

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

https://cloud.alpinux.org ne répond plus. Son certificat a expiré le
4 août 2026, il y a 54 jours.

$ curl https://cloud.alpinux.org
  HTTP 000 — échec TLS

$ openssl s_client -servername cloud.alpinux.org -connect cloud.alpinux.org:443
  subject = CN = cloud.alpinux.org
  notAfter = Aug  4 08:25:44 2026 GMT

Le DNS pointe toujours sur owni (51.91.79.148) : ce n'est pas un service
déplacé, c'est un service en panne.

Pourquoi personne ne l'a vu

owni-certs-sync.sh le signale pourtant, et depuis longtemps :

ORPHELIN  cloud.alpinux.org — expiré depuis 53 j et inconnu de certbot

Le script tourne chaque nuit à 4 h 20 avec --fix --quiet, et MAILTO=root.
Soit le courriel part vers une boîte que personne ne lit, soit il ne part pas.
Un avertissement qui n'atteint personne n'est pas un avertissement — c'est
au moins aussi important à corriger que le certificat lui-même.

Pourquoi le script ne peut pas le réparer seul

Il cherche /etc/letsencrypt/live/cloud.alpinux.org/ et ne le trouve pas :
ce nom n'a pas de certificat à lui chez certbot. Il est en revanche couvert
par le certificat multi-domaines d'alpid.alpinux.org, qui liste
cloud.alpinux.org parmi ses dix noms et reste valide 49 jours.

Le vhost, lui, pointe vers
/var/www/clients/client1/web19/ssl/cloud.alpinux.org-le.crt — la copie
d'acme.sh, expirée.

Deux corrections possibles

Immédiate, sans ISPConfig : faire pointer le vhost — ou plutôt copier le
certificat SAN valide à l'emplacement attendu, comme le script le fait pour
les autres sites. Le HTTPS revient tout de suite. Mais ISPConfig peut écraser
la copie, et c'est exactement le problème que le script existe pour rattraper.

Propre : réémettre depuis ISPConfig (Sites → cloud.alpinux.org → SSL →
Let's Encrypt, décocher, enregistrer, recocher, enregistrer). C'est la voie
que le script recommande lui-même.

À vérifier avant tout

Ce service est-il encore utilisé ? Un certificat expiré depuis 54 jours
sans que personne s'en plaigne pose la question. S'il ne sert plus, le
supprimer d'ISPConfig règle le problème et allège l'inventaire ; s'il sert, il
est hors service depuis presque deux mois.

**`https://cloud.alpinux.org` ne répond plus.** Son certificat a expiré le **4 août 2026**, il y a 54 jours. ``` $ curl https://cloud.alpinux.org HTTP 000 — échec TLS $ openssl s_client -servername cloud.alpinux.org -connect cloud.alpinux.org:443 subject = CN = cloud.alpinux.org notAfter = Aug 4 08:25:44 2026 GMT ``` Le DNS pointe toujours sur owni (`51.91.79.148`) : ce n'est pas un service déplacé, c'est un service en panne. ## Pourquoi personne ne l'a vu `owni-certs-sync.sh` le signale pourtant, et depuis longtemps : ``` ORPHELIN cloud.alpinux.org — expiré depuis 53 j et inconnu de certbot ``` Le script tourne chaque nuit à 4 h 20 avec `--fix --quiet`, et `MAILTO=root`. Soit le courriel part vers une boîte que personne ne lit, soit il ne part pas. **Un avertissement qui n'atteint personne n'est pas un avertissement** — c'est au moins aussi important à corriger que le certificat lui-même. ## Pourquoi le script ne peut pas le réparer seul Il cherche `/etc/letsencrypt/live/cloud.alpinux.org/` et ne le trouve pas : ce nom n'a pas de certificat à lui chez certbot. Il est en revanche **couvert par le certificat multi-domaines** d'`alpid.alpinux.org`, qui liste `cloud.alpinux.org` parmi ses dix noms et reste valide 49 jours. Le vhost, lui, pointe vers `/var/www/clients/client1/web19/ssl/cloud.alpinux.org-le.crt` — la copie d'acme.sh, expirée. ## Deux corrections possibles **Immédiate**, sans ISPConfig : faire pointer le vhost — ou plutôt copier le certificat SAN valide à l'emplacement attendu, comme le script le fait pour les autres sites. Le HTTPS revient tout de suite. Mais ISPConfig peut écraser la copie, et c'est exactement le problème que le script existe pour rattraper. **Propre** : réémettre depuis ISPConfig (*Sites → cloud.alpinux.org → SSL → Let's Encrypt*, décocher, enregistrer, recocher, enregistrer). C'est la voie que le script recommande lui-même. ## À vérifier avant tout **Ce service est-il encore utilisé ?** Un certificat expiré depuis 54 jours sans que personne s'en plaigne pose la question. S'il ne sert plus, le supprimer d'ISPConfig règle le problème et allège l'inventaire ; s'il sert, il est hors service depuis presque deux mois.
Cédric A5L commented 2026-09-27 10:14:47 +02:00
Author
Owner
Copy link

Réparé, et le diagnostic corrige ce ticket

https://cloud.alpinux.org répond de nouveau :

HTTP/2 302
location: https://alpinux.yourownnet.fr/
certificat : notAfter = Nov 16 00:08:36 2026 GMT

Ce que le site est réellement devenu

Il n'héberge plus rien. Le vhost ne fait qu'une redirection vers
https://alpinux.yourownnet.fr/ — le service a déménagé chez un hébergeur
externe.

La panne était donc partielle, et sournoise :
http://cloud.alpinux.org 302, redirigeait correctement
https://cloud.alpinux.org échec TLS, impasse

Autrement dit, ceux qui tapaient l'adresse en clair arrivaient à destination,
et ceux qui avaient le favori en HTTPS — c'est-à-dire presque tout le monde,
les navigateurs préférant HTTPS d'eux-mêmes — se heurtaient à un mur. C'est
sans doute pourquoi personne n'a signalé la panne pendant 54 jours : elle ne
touchait pas tout le monde en même temps.

Pourquoi ISPConfig ne l'a pas réparé

Le site est pourtant bien déclaré, ssl = y et ssl_letsencrypt = y, comme
tous les autres. Mais acme.sh n'a jamais émis pour lui : aucun dossier
/root/.acme.sh/cloud.alpinux.org*.

Le certificat qui servait venait en réalité du certificat multi-domaines de
certbot, qui liste cloud.alpinux.org parmi ses dix noms — recopié un jour
dans web19/ssl/, puis jamais rafraîchi.

Le correctif

Le SAN valide a été recopié à l'emplacement que le vhost attend, les fichiers
expirés étant gardés en .expire-20260804 plutôt qu'écrasés. apache2ctl configtest puis rechargement.

Et ce n'est pas un pansement. Le hook
/etc/letsencrypt/renewal-hooks/deploy/ispconfig-cert.sh itère sur
$RENEWED_DOMAINS — qui contient tous les noms du certificat renouvelé, donc
cloud.alpinux.org — et cherche */ssl/${domain}-le.crt. Ce fichier existant
de nouveau, le hook le maintiendra au prochain renouvellement, dans 49 jours.

owni-certs-sync.sh retourne désormais 0 : plus d'anomalie.

Ce qui subsiste, et qui n'est pas une panne

L'audit garde un avertissement en minuscules :

orphelin  cloud.alpinux.org — inconnu de certbot, expire dans 49 j

Le script cherche un dossier /etc/letsencrypt/live/cloud.alpinux.org/ et n'en
trouve pas, car ce nom n'a pas de certificat à lui : il vit dans le SAN d'un
autre. Le script raisonne par nom de dossier, pas par SAN. Ce n'est pas
grave — il ne fait qu'avertir, et le hook travaille correctement — mais c'est
pourquoi il ne pouvait pas réparer seul.

Deux suites possibles, aucune urgente : apprendre au script à lire les SAN, ou
faire émettre par ISPConfig un vrai certificat pour cloud afin qu'il cesse
d'être un cas particulier.

## Réparé, et le diagnostic corrige ce ticket `https://cloud.alpinux.org` répond de nouveau : ``` HTTP/2 302 location: https://alpinux.yourownnet.fr/ certificat : notAfter = Nov 16 00:08:36 2026 GMT ``` ## Ce que le site est réellement devenu **Il n'héberge plus rien.** Le vhost ne fait qu'une redirection vers `https://alpinux.yourownnet.fr/` — le service a déménagé chez un hébergeur externe. La panne était donc **partielle, et sournoise** : | | | |---|---| | `http://cloud.alpinux.org` | 302, redirigeait correctement | | `https://cloud.alpinux.org` | échec TLS, impasse | Autrement dit, ceux qui tapaient l'adresse en clair arrivaient à destination, et ceux qui avaient le favori en HTTPS — c'est-à-dire presque tout le monde, les navigateurs préférant HTTPS d'eux-mêmes — se heurtaient à un mur. C'est sans doute pourquoi personne n'a signalé la panne pendant 54 jours : elle ne touchait pas tout le monde en même temps. ## Pourquoi ISPConfig ne l'a pas réparé Le site est pourtant bien déclaré, `ssl = y` et `ssl_letsencrypt = y`, comme tous les autres. Mais acme.sh n'a **jamais** émis pour lui : aucun dossier `/root/.acme.sh/cloud.alpinux.org*`. Le certificat qui servait venait en réalité du **certificat multi-domaines de certbot**, qui liste `cloud.alpinux.org` parmi ses dix noms — recopié un jour dans `web19/ssl/`, puis jamais rafraîchi. ## Le correctif Le SAN valide a été recopié à l'emplacement que le vhost attend, les fichiers expirés étant gardés en `.expire-20260804` plutôt qu'écrasés. `apache2ctl configtest` puis rechargement. **Et ce n'est pas un pansement.** Le hook `/etc/letsencrypt/renewal-hooks/deploy/ispconfig-cert.sh` itère sur `$RENEWED_DOMAINS` — qui contient *tous* les noms du certificat renouvelé, donc `cloud.alpinux.org` — et cherche `*/ssl/${domain}-le.crt`. Ce fichier existant de nouveau, le hook le maintiendra au prochain renouvellement, dans 49 jours. `owni-certs-sync.sh` retourne désormais **0** : plus d'anomalie. ## Ce qui subsiste, et qui n'est pas une panne L'audit garde un avertissement en minuscules : ``` orphelin cloud.alpinux.org — inconnu de certbot, expire dans 49 j ``` Le script cherche un dossier `/etc/letsencrypt/live/cloud.alpinux.org/` et n'en trouve pas, car ce nom n'a pas de certificat à lui : il vit dans le SAN d'un autre. **Le script raisonne par nom de dossier, pas par SAN.** Ce n'est pas grave — il ne fait qu'avertir, et le hook travaille correctement — mais c'est pourquoi il ne pouvait pas réparer seul. Deux suites possibles, aucune urgente : apprendre au script à lire les SAN, ou faire émettre par ISPConfig un vrai certificat pour `cloud` afin qu'il cesse d'être un cas particulier.
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#5
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?