Non, aucune installation supplémentaire nécessaire.
De plus, le seul bloc que j’ai dû ajouter est :
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mywebsite.org --keylength"
(La redirection de http vers https semble fonctionner correctement sans les deux autres blocs replace avec nginx)
J’ai enfin trouvé le temps de parcourir les guides « Configuration de Let’s Encrypt avec plusieurs domaines » et « Redirection d’un ou plusieurs domaines vers votre instance Discourse ».
J’ai ajouté beaucoup plus de choses à mon fichier containers/app.yml que vous, et presque tout fonctionne correctement.
Mon Discourse est hébergé sur le sous-domaine www, et mon objectif était de rediriger les requêtes HTTP et HTTPS depuis le domaine de premier niveau (apex) vers le sous-domaine www. Cela fonctionne désormais, mais lorsque je vais sur https://mydomain.com, la redirection s’effectue, mais Chrome affiche l’avertissement suivant dans la console :
Redirection de navigation example.com -> www.example.com car le serveur a présenté un certificat valide pour www.example.com mais pas pour example.com. Pour désactiver ce type de redirection, lancez Chrome avec le drapeau suivant : --disable-features=SSLCommonNameMismatchHandling
Voici mes ajouts au fichier app.yml :
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /return 301 https.+/
to: |
return 301 https://$host$request_uri;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /gzip on;[^\}]+\}/m
to: |
gzip on;
add_header Strict-Transport-Security 'max-age=31536000'; # mémoriser le certificat pendant un an et se connecter automatiquement en HTTPS pour ce domaine
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
Cela semble-t-il correct ? Si oui, existe-t-il une solution au problème de mismatch de nom de certificat ?
MODIFICATION : J’ai deux enregistrements A, l’un pour le sous-domaine www et l’autre utilisant @ pour capturer toutes les requêtes vers le domaine de premier niveau. Tous deux pointent vers l’adresse IP de mon droplet Digital Ocean. Je suppose que cela est également correct ?
Merci.
Gratuit à mettre en œuvre, même si Cloudflare n’est pas votre registraire. Fonctionne avec HTTPS, sans complexité supplémentaire dans votre installation Discourse.
Merci, je n’utilise pas actuellement Cloudflare, donc je n’avais pas encore rencontré ces éléments. J’ai emprunté une autre voie et suivi les guides ci-dessus, et j’ai réussi en grande partie à résoudre mon problème. Vous avez posté juste au moment où je soumettais ma réponse ci-dessus.
Veuillez vérifier ce site web ; contient-il tous les redirections dont vous avez besoin ? Tout est réalisé avec un seul bloc replace (voir ci-dessus) et cette configuration DNS (j’ai seulement masqué les enregistrements TXT relatifs aux e-mails) :
Je ne reçois aucun avertissement dans la console.
Oui, soyez simplement prêt à ce que cela plante lorsque la configuration de Let’s Encrypt changera.
Lorsque Let’s Encrypt a été mis à jour pour prendre en charge les courbes elliptiques, l’approche sur laquelle vous vous appuyez ci-dessus a été mise hors service pendant quelques semaines.
La seule différence est que je n’ai pas d’enregistrement CAA dans mon DNS. Je vais l’ajouter avec la même valeur que vous avez utilisée.
Je suppose que votre nom d’hôte Discourse est www.example.com. Êtes-vous certain de ne pas recevoir d’avertissement lorsque vous accédez à https://example.com ?
L’avertissement est encore plus grave avec Chrome sur Android : il bloque complètement le site et ne redirige pas.
Vous m’avez perdu maintenant 
De quoi dois-je faire attention ou être prêt à corriger ?
C’est exact.
Oui, je n’ai aucun avertissement dans la console.
Je pense avoir trouvé le problème. J’avais ceci :
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
Alors que j’aurais dû avoir :
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com --keylength"
Remarquez la dernière ligne : j’avais example.com et www.example.com.
J’ai également remplacé return 301 https://$host$request_uri; par return 301 $scheme://$host$request_uri;. Après une nouvelle reconstruction, cela semble fonctionner.
Je suis maintenant simplement préoccupé par ce que @Stephen a mentionné concernant le risque de rupture lors de modifications de la configuration de Let’s Encrypt.
Un changement intervenu le 9 septembre de l’année dernière a rompu l’approche que vous suivez, et comme la mise en œuvre ne relevait pas de l’installation standard, une solution n’a été publiée que le 31 octobre. Si vous examinez le sujet que vous avez suivi et l’historique des modifications sur le wiki, tout y est clairement documenté.
Puisque vous n’avez pas à effectuer une opération nécessitant de vous plonger dans une configuration supplémentaire, je vous déconseille de le faire. En revanche, lorsque Let’s Encrypt effectuera un changement et que vous serez concerné, nous pourrons vous renvoyer vers ce sujet.