La Fibre
Fonctionnement du forum => A lire avant de commencer... => Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: Zweit le 08 septembre 2022 à 06:55:25
-
Salut,
Ce matin, petit message d'alerte concernant le certificat du forum indiquant qu'il est expiré :)
-
Après quelques minutes, c'est revenu à la normale.
Toutefois, le certificat indique qu'il date d'aout dernier ???
-
Finalement ce n'est pas réglé, le certificat expiré vient de revenir ???
-
Le certificat du site est un certificat LetsEncrypt qui se renouvelle automatiquement. Chez moi, je vois qu'il est valable depuis le 9 Août, et expire le 7 Novembre. Donc il n'a pas expiré aujourd'hui. Le problème est donc plutôt chez toi. Tu es sûr d'aller sur le bon site ? Ou un effet de cache de ton navigateur ? Essaye un autre navigateur, et éventuellement efface ton cache ?
Pas avant Tue, 09 Aug 2022 00:31:15 GMT
Pas après Mon, 07 Nov 2022 00:31:14 GMT
-
Le certificat du site est un certificat LetsEncrypt qui se renouvelle automatiquement. Chez moi, je vois qu'il est valable depuis le 9 Août, et expire le 7 Novembre. Donc il n'a pas expiré aujourd'hui. Le problème est donc plutôt chez toi. Tu es sûr d'aller sur le bon site ? Ou un effet de cache de ton navigateur ? Essaye un autre navigateur, et éventuellement efface ton cache ?
J'ai eu le coup ce matin, du SSL qui n'était pas renouveller.
Peut être un des certificat du load balancing n'est pas à jour ?
-
Le load balancing, ce n'est pas plutôt une bascule entre interface IPv4 et IPv6 ? Il me semble qu'à cause des attaques DDOS, la fibre a un réseau de secours géré par Milkywan ?
-
Le serveur n'a pas de load blancing: il y a un seul serveur qui a deux interfaces réseau : une pour IPv4 avec MilkyWan et une IPv6 avec Adeli. Adeli prend en charge tout le trafic IPv6 et MilkyWan tout le trafic IPv4.
IPv4 ou IPv6, c'est le même serveur qui répond avec le même certificat et le même contenu.
Le certificat Let's Encrypt n'a pas expiré. Le DNS n'a pas changé.
D'autres personnes sont impactées ?
Je ne comprends pas d'où vient le problème.
La date et l'heure de ton PC sont ok ? (pile CMOS usée par exemple qui fait que la date est invalide)
-
RAS ici
-
J'ai été impacté vers 8h sur un pixel 6. Après un nouveau chargement de la page. Ras
-
Je viens de l'avoir à l'instant, en passant d'une page à l'autre (page 14 à 15 sur le fil de la prolongation de l'iti).
-
J'ai moi aussi rencontré le problème et je viens de redémarrer le serveur. Je pense que cela devrait corriger le bug.
Ce qui se passait : Le serveur Apache renvoie (aléatoirement) l'ancien certificat Let's Encrypt, qui a expiré le 07 Sep 2022 13:39:12.
Les certificats Let's Encrypt ont une durée de validité de 3 mois et sont renouvelés tous les 2 mois.
On a donc le précédent certificat qui est valide un mois alors qu'il n'est normalement plus présenté.
Pourquoi le serveur s'est mis à renvoyer l'ancien certificat, alors que le nouveau est présent depuis 1 mois sur le système ? C'est visiblement un bug Apache.
J'ai ma petite idée pour comprendre pourquoi c'est arrivé aujourd'hui et pas avant : Je teste le service "canonical-livepatch" qui permet de patcher le noyau sans redémarrer le serveur et donc je n'avais plus redémarré le serveur depuis début juillet 2022. Avant, je redémarrais le serveur environ tous les mois pour prendre en charge les modifications du noyau. Si l'ancien certificat était présenté avant le reboot, on restait donc dans sa période de validité.
-
Peut-être que certains processus du serveur Apache n'avaient pas chargé le nouveau certificat, et que donc selon la répartition des connexions on pouvait avoir l'un ou l'autre.
Quand le certificat est changé, est-ce qu'il y a quelque chose qui demande à Apache de recharger sa configuration ("systemctl apache2 reload", "apachectl graceful" ou "apache2 -k graceful") ?
-
Non, je ne pense pas que Certbot (https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal), le script que j'utilise pour renouveler le certificat, relance Apache.
Je pensais que c'était fait par logrotate.
Dans le fichier /etc/logrotate.d/apache2 j'ai :
/var/log/apache2/*.log {
daily
missingok
rotate 3
nocompress
notifempty
create 644 root adm
sharedscripts
postrotate
if invoke-rc.d apache2 status > /dev/null 2>&1; then \
invoke-rc.d apache2 reload > /dev/null 2>&1; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
Dans le passé, j'ai souvenir que logrotate relançait Apache pour le changement de nom de fichier de log et dans le fichier /etc/apache2/mods-enabled/mpm_event.conf, j'avais mis "GracefulShutdownTimeout 3600" pour que les connexions ouvertes sans fin soient fermées après 1h, car j'avais été confronté à des connexions ouvertes pendant des dizaines d'heures (slowDDoS ?) qui bloquait le redémmarrage d'Apache.
Maintenant que logrotate ne relance plus régulièrement Apache, il faut probablement mettre une commande à Apache pour qu'un process Apache n'ait pas une durée de vie infinie.
-
Pour mon expérience, c'est plutôt nginx que l'on utilise, et certbot relance bien nginx, en tout cas avec Letsencrypt. Certbot peut être utiliser aussi pour renouveler des certificats Sectigo, par exemple, mais là, il faut modifier à la main la configuration, et relancer le serveur web.
https://sectigo.com/resource-library/sectigos-acme-automation
-
En effet, logrotate devrait appeler "invoke-rc.d apache2 reload" (cad "systemctl apache2 reload") tous les jours.
Tu peux regarder avec "journalctl --unit=apache2" (ou dans les /var/log/syslog* si tu n'as pas journald).
Normalement tous les jours tu dois avoir :
systemd[1]: Reloading The Apache HTTP Server.
systemd[1]: Reloaded The Apache HTTP Server.
-
certbot relance bien nginx
Quand je demande un certificat à certbot, je le demande en mode "certonly" pour qu'il ne touche pas à ma configuration Apache :
sudo certbot --apache --domains lafibre.info,www.lafibre.info certonly
Sinon Apache est bien relancé par logrotate, il le fait même 4 fois chaque jour !
Log pour lafibre.info :
sept. 01 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 01 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 01 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 01 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 02 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 02 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 02 00:00:03 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 02 00:00:03 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 03 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 03 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 03 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 03 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 04 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 04 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 04 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 04 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 05 00:00:03 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 05 00:00:03 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 05 00:00:04 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 05 00:00:04 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 06 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 06 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 06 00:00:03 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 06 00:00:03 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 07 00:00:02 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 07 00:00:02 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 07 00:00:03 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 07 00:00:03 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 08 00:00:00 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 08 00:00:00 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 08 00:00:01 lafibre systemd[1]: Reloading The Apache HTTP Server.
sept. 08 00:00:01 lafibre systemd[1]: Reloaded The Apache HTTP Server.
sept. 08 09:29:46 lafibre systemd[1]: Stopping The Apache HTTP Server...
sept. 08 09:29:56 lafibre systemd[1]: apache2.service: Succeeded.
sept. 08 09:29:56 lafibre systemd[1]: Stopped The Apache HTTP Server.
-- Reboot --
sept. 08 09:30:56 lafibre systemd[1]: Starting The Apache HTTP Server...
sept. 08 09:30:56 lafibre systemd[1]: Started The Apache HTTP Server.
-
J'utilise certbot dans le mode pas défaut, run. Pour nginx, de mon expérience, il touche à la configuration de façon propre, sans rien casser autrement. C'est quand même plus sûr qu'il fasse tout automatiquement, on n'a pas à intervenir, par exemple si on est indisponible, en congés... C'est l'assurance que le certificat sera bien renouvelé.
-
Pourquoi ne pas mettre un certificat pour 2 ans ?
Orange fait ça ici -> https://www.digicert.com/fr/tls-ssl/compare-certificates
-
Parce que Google, Apple... n'acceptent plus les certificats de plus d'un an. De ce côté là aussi, Letsencrypt, qui les renouvelle tous les 3 mois, est très pratique. Il est plus facile de révoquer un certificat qui a une durée de vie limitée, qui viendra de toute façon à expiration, qu'un à longue durée.
https://www.hosteur.com/ressources/articles/validite-ssl
-
Sinon Apache est bien relancé par logrotate, il le fait même 4 fois chaque jour !
C'est deux fois (reloading, reloaded c'est le début et la fin de la même action), et immédiatement l'une derrière l'autre (peut-être que ça peut déclencher le bug).
-
Le double reload est lié au fait que j'ai deux dossiers pour les logs avec des durées différentes.
- /var/log/apache2/ est en ramdisque avec une durée de seulement 3 jours.
- /home/log/ est sur SSD avec une durée de 70 jours
L'objectif est de limiter les écritures sur SSD pour ce qui n'est pas important.
Voici mon fichier /etc/logrotate.d/apache2 complet :
/var/log/apache2/*.log {
daily
missingok
rotate 3
nocompress
notifempty
create 644 root adm
sharedscripts
postrotate
if invoke-rc.d apache2 status > /dev/null 2>&1; then \
invoke-rc.d apache2 reload > /dev/null 2>&1; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
/home/log/*/*.log {
daily
missingok
rotate 70
nocompress
notifempty
create 644 root adm
sharedscripts
postrotate
if invoke-rc.d apache2 status > /dev/null 2>&1; then \
invoke-rc.d apache2 reload > /dev/null 2>&1; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}
Il y a peut-être un moyen de faire ça plus proprement.