[Résolu]"htaccess inopérant" sur un site fonctionnel

Bonjour,

Je suis désolée d’aborder un sujet qui semble rebattu, presque « tabou », mais je n’ai pas trouvé de réponse qui corresponde à ma situation.

Versions
SPIP 4.3.5
PHP Version 8.3.15
MariaDB version 10.11.6
Debian 12

Problème
La page de maintenance technique d’un spip fraîchement installé via spip_loader affiche le message « htaccess inopérant… ».
Pourtant…
Le fichier htaccess.txt a été renommé. .htaccess, il est parcouru lorsqu’on accède au site et rewrite est installé, activé et accessible (passe le test de ce tuto). Le site est accessible et fonctionnel en accès privé comme en accès public anonyme. Les URL propres fonctionnent. Bref, à part ce message d’avertissement, tout semble OK.

Environnement
Le serveur est sur un LAN bloquant les requêtes http[s] provenant d’ Internet mais accessible depuis tout poste du LAN. Le nom de domaine n’est résolu qu’à l’intérieur du LAN. Tout poste du LAN accède au site sans problème, via son nom de domaine.

Enfin, le site est à la racine d’un VirtualHost d’Apache2.


Toute piste est la bienvenue… Merci d’avance !

Le message veut dire que potentiellement on peut accéder à tmp et config. Est-ce le cas ? si oui il est possible que ce soit effectivement inopérant.

Merci pour cette information et la piste qu’elle ouvre !
Je viens de tenter d’accéder à l’index des deux répertoires comme aux fichiers qu’ils contiennent. Toutes mes tentatives se soldent par une erreur 403.
Pour chacune de ces requêtes, les log d’Apache2 signalent : [authz_core:error] … client denied by server configuration

Alors c’est « juste » du à ce bug Detection .htaccess pas fiable lors de l'installation (#3172) · Tickets · spip / spip · GitLab

Super ! Merci @b_b pour cette pépite !
Je pense être dans le cas du bug dû au certificat auto-signé. Je ne comprenais pas l’apparition de ce problème car mon serveur sur le LAN possède la même configuration qu’un autre serveur, ouvert sur l’internet, qui lui ne rencontrait pas le problème de faux négatif. Au niveau réseau, ça devait être équivalent (et ça l’est). Mais le serveur ouvert à un certificat Let’s Encrypt. La différence viendrait de là…
Bien sûr, ça oblige à faire les tests à la mano mais surtout à ignorer un message qui pourrait devenir pertinent en cas de modification inopinée de la configuration Apache/VirtualHost.