Domaine personnalisé & TLS

Pointer votre site vers votre propre domaine, et obtenir des certificats HTTPS qui se renouvellent seuls (ou que vous gérez intentionnellement), est une courte séquence : pointer le DNS, choisir l'orthographe canonique, configurer le proxy, vérifier TLS. Ce guide la parcourt avec les réglages et les contrôles attendus par le logiciel.

Étape 1 : Pointer le domaine

• Ajoutez un enregistrement DNS A/AAAA pour votre domaine public (et un autre pour l'admin, par exemple admin.example.com, si vous utilisez le schéma des exemples), pointant vers votre serveur.
• Pour les sites multilingues, décidez tôt si chaque langue reçoit son propre sous-domaine ou vit sous un seul hôte (les deux dispositions sont livrées, voir Reverse Proxy). Le mode sous-domaine signifie des adresses du type es.example.com pour chaque langue.

Le DNS est entièrement en dehors du logiciel : aucun fournisseur n'est présumé.

Étape 2 : Définir votre URL canonique

Dans Settings, définissez Site URL : l'orthographe exacte que vous voulez comme unique vraie adresse du site, y compris l'usage ou non de www.

Pourquoi ce réglage unique compte :

• Chaque URL de page canonique, chaque entrée de sitemap, chaque adresse de flux est générée à partir de lui.
• Le build écrit une règle de redirection permanente (301) qui envoie l'*autre* orthographe de votre hôte (celle que vous n'avez pas choisie) vers celle que vous avez choisie, ainsi moteurs de recherche et visiteurs atterrissent sur une seule adresse.
• En mode sous-domaine linguistique, les URL de chaque langue sont automatiquement réécrites vers son propre sous-domaine d'après ce réglage.

Réglez cela correctement d'abord ; cela décide de ce que sera chaque adresse générée.

Étape 3 : Configurer le proxy et les certificats

• Caddy (recommandé) : déposez vos domaines dans la configuration d'exemple. C'est tout : Caddy demande et renouvelle automatiquement les certificats Let's Encrypt dès que votre DNS pointe vers le serveur et que les ports 80/443 sont joignables. Aucune ligne de certificat à gérer.
• nginx : mettez en place le vhost HTTP depuis l'exemple livré, puis lancez Certbot pour votre domaine ; il injecte pour vous l'écouteur HTTPS et les références de certificat.
• Gardez le CMS lié au loopback (par exemple 127.0.0.1:3001) et laissez le proxy faire le TLS. Contrôle : après le premier démarrage, curl -I https://your.admin.domain doit répondre proprement.
• N'oubliez pas les petites règles de proxy : /forms/ si votre site a des formulaires, /documents/ si vous utilisez les documents, et la liste honeypot (toutes livrées dans les exemples).

Étape 4 : Vérifier

Contrôles avant de déclarer terminé :

• La page publique en HTTPS se charge sans avertissements de contenu mixte (le CMS et le proxy envoient tous deux les bons en-têtes de cache/sécurité).
• Le domaine d'admin répond aussi en HTTPS.
• L'orthographe d'hôte non canonique redirige vers celle choisie (ou votre règle d'hôte au niveau du Caddyfile le fait, voir ci-dessous).
• L'URL de chaque langue répond sur son hôte/sous-domaine attendu.

Les détails qui comptent

• L'application de la règle canonique est la plus forte sur les hôtes qui lisent le fichier de redirection au format Netlify: le build écrit une règle 301 au niveau de l'hôte dans _redirects. Sur les déploiements Caddy, le fichier de règles équivalent ne l'inclut pas, donc ajoutez la redirection d'hôte dans votre Caddyfile quand vous avez besoin de la redirection stricte (les balises canoniques par page proviennent du CMS sur chaque hôte).
• HSTS est émis par le CMS pour le trafic d'admin (un an, sous-domaines inclus) et reflété dans l'exemple nginx livré ; une fois que les navigateurs l'ont vu, le TLS doit rester présent, donc assurez-vous que les renouvellements fonctionnent avant de vous y fier.
• Mappage de ports : chaque instance garde un port unique (3001, 3002, …) derrière le proxy ; le proxy route chaque domaine vers son instance. Si vous adoptez le Manager, vous y attachez les domaines et il régénère/recharge la configuration du proxy pour vous ; le daemon lui-même ne quitte jamais le loopback.
• Hôtes extrêmement air-gapped : il existe un mode documenté sans DNS et sans certificats : HTTP simple sur un port local, protégé par VPN/pare-feu au lieu de TLS. C'est la soupape d'échappement délibérée quand le renouvellement est impossible ; traitez-la comme un déploiement de sécurité physique.

De quoi ne pas s'inquiéter

• Le logiciel n'a jamais besoin d'un fournisseur DNS ni d'une connexion API pour les domaines.
• Le renouvellement des certificats (dans les déploiements normaux) est géré par le proxy, pas par le CMS.
• Les en-têtes de sécurité arrivent du CMS sur chaque réponse indépendamment de la configuration du proxy ; les exemples ne les dupliquent que comme filet de sécurité.

La version courte

Pointez le DNS, fixez l'orthographe canonique dans Settings, placez le proxy devant avec Let's Encrypt pour les certificats (ou choisissez délibérément le mode hors ligne sans TLS), vérifiez avec curl -I, et les variantes www/sans www aboutissent toutes deux au même domaine, définitivement.