Renouvellement de certificat sur domaine en redirection seule

Salut,

je suis sur une 4.1.8 (je vais sans doute tenter la migration pour la 4.2 ce week-end). En plus de mon domaine principal (ci-après désigné comme « domain.tld »), je me suis créé un domaine secondaire (« www.domain.tld ») destiné aux bidouilles.

En l’état, ce domaine est une simple redirection vers le domaine principal, c’est-à-dire que j’ai modifié le fichier de conf’ nginx pour qu’il contienne ceci :

location / {
    return 301 https://domain.tld$request_uri;
}

Comme ça, les gens qui mettraient par erreur un « www. » dans leur barre d’URL arrivent quand même sur la page qu’ils veulent, et moi ça me fait un endroit où installer des choses pour tester sans que ce soit directement accessible publiquement (soit dit en passant, c’est aussi, du coup, le domaine que j’utilise pour permettre la connexion XMPP anonyme).

Ça a bien marché pendant tout le temps où le certificat Let’s Encrypt pour ce domaine était valide, mais maintenant qu’il faudrait un renouvellement, je reçois un mail automatique me disant ceci :

/etc/cron.daily/yunohost-certificate-renew:
Le challenge ACME n’a pas pu être validé pour le domaine www.domain.tld pour le moment car le code de la configuration nginx est manquant… Merci de vérifier que votre configuration nginx est à jour avec la commande: yunohost tools regen-conf nginx --dry-run --with-diff.

J’imagine que ça vient du réglage de conf’ mentionnée plus haut, à savoir que quelle que soit l’URL que tu demandes sur ce domaine, tu te manges une redirection automatique, ça ne doit pas plaire à l’outil de vérif.
Je pourrais simplement remettre la conf’ de base le temps du renouvellement, mais si je dois faire ça à chaque fois, ça perd l’intérêt d’un renouvellement automatique. J’aimerais bien garder ce domaine en l’état.

Du coup, sauriez-vous par hasard m’indiquer quelle manip’ je pourrais faire pour que la validation Let’s Encrypt se fasse sans trop modifier le reste ? J’imagine qu’il suffit de faire en sorte qu’une adresse particulière réponde autre chose qu’une 301, mais je n’y connais pas grand chose en certificats.

Normalement le bout de conf nginx qui gère la route pour lets encrypt est déjà faite de sorte à ce qu’elle soit prioritaire

Est-ce que tu peux élaborer sur :

  • est-ce que tu as fait la bidouille dans /etc/nginx/conf.d/domain.tld.conf, ou bien tu as créé un fichier dans domain.tld.d/
  • est-ce qu’il y a d’autres messages qui pourraient être lié au probleme dans le diagnostique

Ah, oui, je n’ai pas tout détaillé, en effet, désolé ^^’

À la base, j’avais tenté le fichier le simple fichier dans www.domain.tld.d, ne contenant que la conf’ sus-mentionnée, sauf que, juste avec ça, ça redirigeait vers le portail YunoHost plutôt que vers la page demandée. Je suppose que le sso ne voyait pas d’appli autorisée directement sur / et donc ne voulait pas laisser l’accès. Du coup, j’ai viré le fichier dans .d et j’ai directement modifié le www.domain.tld.conf en virant les lignes qui me semblaient être potentiellement responsables de la redirection prioritaire.

Voilà l’intégralité de la section concernée dans le .conf :

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.domain.tld;

    include /etc/nginx/conf.d/security.conf.inc;

    ssl_certificate /etc/yunohost/certs/www.domain.tld/crt.pem;
    ssl_certificate_key /etc/yunohost/certs/www.domain.tld/key.pem;

    more_set_headers "Strict-Transport-Security : max-age=63072000; includeSubDomains; preload";

    # OCSP settings
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/yunohost/certs/www.domain.tld/crt.pem;
    resolver 127.0.0.1 127.0.1.1 valid=300s;
    resolver_timeout 5s;
    
    location / {
        return 301 https://domain.tld$request_uri;
    }
}

Et du coup, pour le diagnostique, dans configuration système, il me signale que le fichier www.domain.tld a été modifié, et dans web, que « la configuration Nginx de ce domaine semble avoir été modifiée manuellement et empêche YunoHost de diagnostiquer si elle est accessible en HTTP ». Je lui ai demandé d’ignorer les deux.

S’il y a une manip’ à faire pour rétablir le fichier .conf dans son état d’origine, mais en faisant en sorte que la redirection sur / soit bien prise en compte, ça m’intéresse aussi, du coup, tant qu’à faire je préférerais que la seule modif’ de ma part soit un fichier spécifique dans le .d :slight_smile:

Hmokay mais le truc avec Lets Encrypt se passe sur le port 80, donc qu’en est-il de la partie sur le port 80 ?

Ah. Bah je n’ai pas fait dans la dentelle, même modif’ pour le port 80, mais vu qu’il n’y avait pas les lignes liées au certificat, ça donne un truc encore plus simple :

server {
    listen 80;
    listen [::]:80;
    server_name www.domain.tld;

    location / {
        return 301 https://domain.tld$request_uri;
    }
}

J’imagine que je peux restaurer le fichier de conf’ dans son état de base pour le port 80, en laissant la modif’ sur le port 443, mais dans ce cas, il y aurait un comportement différent selon si les gens viennent en http ou en https…

S’il y a moyen de dire au SSO de ne pas rediriger vers le portail prioritairement au fichier disant quoi faire pour /, et donc que ça permette de restaurer le fichier .conf dans son état d’origine, je prends, ça me semblerait être la meilleure solution.
Sinon, je veux bien savoir quelle ligne spécifique je dois remettre pour que les tests marchent mais la redirection aussi.

Mokay ben pourtant dans la conf du serveur port 80 y’a pas juste 2 lignes useless …

En l’occurence, pour lets encrypt c’est le include /etc/nginx/conf.d/acme-challenge.conf.inc

Mais les autres lignes sont pas non plus là pour rien …

Beh, le access_by_lua_file, est la ligne que je suis obligé de virer pour avoir accès au / sans installer d’appli spécifique, il me semble. Le include .d/*.conf correspond aussi plutôt à ce que je veux dans ce domaine, et la redirection sur /yunohost devient redondante à partir du moment où j’ai une redirection équivalente sur / directement (la retirer est même je pense plutôt préférable, dans la mesure où, si elle y est, ça fait une première redirection vers le même domaine mais en https, puis une seconde vers le domaine principal, autant rediriger directement vers l’adresse finale). Pour les logs, je ne suis pas convaincu que ça ait une utilité énorme…
À quoi sert la ligne concernant le mail, au juste ? N’ayant pas l’intention d’avoir de mail sur ce domaine, j’aurais tendance à supposer qu’elle ne servira pas à grand chose, mais pour autant que je sache, c’est la première fois que je croise un réglage relatif au mail dans la config web.

En tout cas, j’ai remis la ligne pour le challenge ACME, ainsi que celle pour le diagnostique, et ça a effectivement tout remis en ordre, merci beaucoup :slight_smile:
(Et j’ai bien fait la migration vers la 4.2 depuis, tout marche très bien)