Comment configurer un domaine personnalisé avec TLS en 5 minutes (avec Elido)

Configurer un domaine personnalisé avec HTTPS prend deux enregistrements DNS et environ trois minutes d'attente pour la propagation. Le reste du temps est généralement passé à comprendre ce que signifient les enregistrements, pourquoi les deux sont nécessaires et ce qui se passe après leur ajout. Cet article est la version pratique : cinq étapes concrètes, l'appel API exact, et une explication de la machinerie de certificat pour que vous sachiez quoi faire quand quelque chose tourne mal.

Pourquoi TLS compte pour les liens courts spécifiquement#

Un lien court sans HTTPS est une responsabilité d'une manière qu'une URL ordinaire sans HTTPS ne l'est pas.

La réponse de redirection - un 301 ou 302 avec un en-tête Location - est le payload entier. Si la requête HTTP initiale voyage sur du HTTP en clair, n'importe qui sur le chemin réseau peut lire l'URL de destination avant que le client ne la suive. Cela signifie que la destination de votre campagne, votre URL d'affiliation ou votre lien d'outil interne est visible à tout observateur de réseau sur le premier saut. Les navigateurs modernes ont commencé à faire ressortir des avertissements de sécurité sur les liens courts HTTP précisément à cause de ce pattern d'exposition.

Les codes QR aggravent le problème. Une personne qui scanne un code dans un espace physique n'a aucune relation préalable avec l'URL - le code est le signal de confiance entier. Un avertissement de navigateur au premier chargement est le pire point de friction possible : vous avez déjà payé pour le tirage d'impression, l'emplacement événementiel ou les médias OOH, et un avertissement de sécurité au scan est la chose la plus susceptible de faire fuir une personne curieuse. Un certificat TLS valide sous votre propre domaine est le signal de confiance le moins cher que vous puissiez acheter pour une campagne basée sur QR.

Sur s.elido.me ou b.elido.me, le certificat TLS appartient à Elido. Le cadenas est réel, mais le domaine n'est pas le vôtre, ce qui signifie que la confiance de marque s'accumule sur la plateforme, pas sur vous. Un domaine personnalisé sous go.acme.com met votre nom sur le certificat.

Plus de détails sur les fondamentaux DNS et TLS dans l'article cornerstone : Liens courts à domaine personnalisé : DNS, TLS et ce qui tourne à l'edge.

Étape 1 : choisissez le hostname#

Le choix le plus courant est un sous-domaine court de votre domaine principal : go.example.com, links.example.com ou s.example.com. Plus court c'est mieux - le préfixe de sous-domaine apparaît dans chaque lien que vous envoyez.

Deux contraintes à connaître avant de décider :

Sous-domaine uniquement, sauf si votre fournisseur DNS supporte les enregistrements ALIAS. RFC 1034 §3.6.2 interdit les enregistrements CNAME à l'apex de zone (example.com). Si vous voulez que l'apex nu redirige, votre fournisseur DNS doit supporter les enregistrements ALIAS ou ANAME (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS). Ce sont des extensions non standard qui aplatissent la recherche avant publication. Vérifiez la documentation de votre fournisseur ; le nom de la fonctionnalité varie et tous les fournisseurs ne l'offrent pas.

Choisissez un sous-domaine que vous n'utilisez pas pour autre chose. links.example.com redirigeant via Elido ne doit pas avoir aussi un enregistrement A pointant vers votre serveur web ou un CNAME existant. Les enregistrements DNS pour le même nom doivent être cohérents.

Pour la plupart des équipes : go.example.com ou links.example.com convient. Choisissez-le, notez-le, et passez à l'étape 2.

Étape 2 : enregistrer le domaine dans Elido#

Ouvrez Settings → Custom Domains → Add Domain dans le tableau de bord, entrez votre hostname et cliquez sur Add. La réponse est deux valeurs d'enregistrement DNS : un token de vérification et la cible CNAME. Vous utiliserez les deux à l'étape 3.

Si vous scriptez ceci - onboarding d'un nouveau workspace client, l'exécuter dans le cadre d'un pipeline de déploiement, ou la gestion avec le provider Terraform - l'appel API est :

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "go.example.com",
    "is_wildcard": false
  }'

Le corps de réponse inclut un verification_token (une chaîne hexadécimale aléatoire) et des instructions contenant les valeurs exactes d'enregistrement DNS :

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending_verification"
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

Les domaines personnalisés sont disponibles sur les forfaits payants. Le forfait Business est le point d'entrée pour les domaines personnalisés ; les agences gérant plusieurs domaines clients sous une seule organisation devraient regarder le modèle workspace sur la page solutions agences.

Étape 3 : ajouter les deux enregistrements DNS#

Allez au panneau de contrôle de votre fournisseur DNS et ajoutez les deux enregistrements de l'objet instructions. Vous avez besoin des deux - le CNAME route le trafic vers l'edge d'Elido ; l'enregistrement TXT prouve que vous possédez le domaine avant qu'Elido n'accepte de le servir.

Pour un sous-domaine ordinaire :

go.example.com              CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

Pour un domaine wildcard (forfait Business, couvre *.go.example.com) :

*.go.example.com            CNAME  edge.elido.me.
_elido-verify.go.example.com  TXT    "verify=<your-token>"

Le préfixe _elido-verify est une convention de challenge DNS standard - il place la preuve de propriété sur un sous-domaine du hostname à vérifier, pour que l'enregistrement TXT ne puisse pas entrer en collision avec le CNAME.

Quelques notes spécifiques aux fournisseurs :

• Cloudflare : ajoutez les deux enregistrements. Laissez le toggle de proxy CNAME off (nuage gris, DNS-only). Le proxy HTTP de Cloudflare dépouille le hostname original avant qu'il n'atteigne l'edge d'Elido, ce qui casse la vérification d'autorisation CaddyAsk. Le mode DNS-only passe la requête sans modification.
• AWS Route 53 : utilisez un enregistrement ALIAS si vous avez besoin de l'apex ; pour les sous-domaines, un CNAME simple est correct. Route 53 ne supporte pas CNAME à l'apex de zone mais supporte ALIAS vers des cibles externes.
• GoDaddy / Namecheap / la plupart des DNS de registrar : CNAME et TXT standards - pas de configuration spéciale.

Réglez le TTL des deux enregistrements à 300 secondes (5 minutes) si votre fournisseur le permet. Le TTL par défaut pour beaucoup de zones gérées est de 3600 secondes ; un TTL plus court signifie une confirmation de propagation plus rapide et une récupération plus rapide si vous devez changer les enregistrements plus tard.

Étape 4 : attendre la vérification#

Une fois les enregistrements en place, domain-manager les poll automatiquement en utilisant le resolver public de Google (8.8.8.8) à un intervalle court. Vous n'avez pas besoin de cliquer sur « Verify now ».

Le service vérifie deux conditions avant de marquer le domaine actif :

1. _elido-verify.go.example.com retourne un enregistrement TXT dont la valeur est verify=<token> - cela confirme que vous contrôlez la zone DNS.
2. go.example.com se résout via CNAME vers edge.elido.me - cela confirme que le trafic atteindra l'edge d'Elido.

Quand les deux vérifications passent, status passe de pending_verification à verified. Vous pouvez poller ceci vous-même :

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

Surveillez le champ status. Le temps de propagation typique pour les enregistrements posés avec un TTL de 300s est sous 5 minutes. Les enregistrements au TTL par défaut de 3600s peuvent prendre jusqu'à une heure si vous êtes dans une partie du monde où les resolvers sont agressifs sur le caching.

Si la vérification stagne, vérifiez que vos enregistrements sont publiés correctement :

dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short

La recherche TXT devrait retourner "verify=<your-token>". La recherche CNAME devrait retourner edge.elido.me. (point final normal).

Étape 5 : la première requête émet le certificat automatiquement#

Une fois que domain-manager marque le domaine vérifié et l'enregistre auprès de Caddy, vous avez terminé de votre côté. TLS se produit sans aucune action supplémentaire.

Le mécanisme est le TLS à la demande de Caddy (ADR-0012) : plutôt que de pré-émettre des certificats pour chaque domaine vérifié, Caddy émet le certificat au premier handshake TLS pour un nouveau hostname. Avant de tenter l'émission ACME, Caddy appelle l'endpoint CaddyAsk de domain-manager - un simple HTTP GET ?domain=go.example.com. Si domain-manager retourne 200 (le domaine est en état vérifié ou actif), Caddy procède. S'il retourne 404, le handshake TLS échoue et aucun certificat n'est jamais demandé. Cette barrière est la dernière ligne de défense contre la mauvaise émission de certificat pour des hostnames non reconnus.

Quand Caddy procède, le flux ACME (RFC 8555) exécute un challenge HTTP-01 :

1. Caddy demande une nouvelle commande à Let's Encrypt.
2. Let's Encrypt répond avec un token de challenge : placez-le à http://go.example.com/.well-known/acme-challenge/<token>.
3. Caddy place le token dans son gestionnaire HTTP en mémoire.
4. Let's Encrypt récupère le token via HTTP en clair et le valide.
5. Le certificat est émis, stocké dans le cache de certificats de Caddy, et la requête HTTPS originale est servie.

Les étapes 1 à 5 ajoutent environ 2 à 3 secondes de latence à la toute première requête vers un domaine nouvellement vérifié. Chaque requête suivante utilise le certificat en cache sans surcoût. Caddy gère le renouvellement automatiquement avant l'expiration.

Elido émet des certificats ECDSA P-256 pour tous les domaines personnalisés. Les signatures P-256 sont plus petites et plus rapides à vérifier que RSA-2048, ce qui compte à l'edge où les handshakes TLS sont sur le chemin chaud.

Pièges courants#

Enregistrements CAA bloquant Let's Encrypt. Les enregistrements Certification Authority Authorization (CAA) spécifient quelles autorités de certification sont autorisées à émettre des certificats pour un domaine. Si votre zone DNS a example.com CAA 0 issue "digicert.com", Let's Encrypt refusera d'émettre un certificat pour go.example.com parce qu'il hérite de la politique CAA de l'apex. Le remède : ajouter go.example.com CAA 0 issue "letsencrypt.org", ou supprimer la restriction de l'apex si votre politique de sécurité le permet. L'endpoint de statut de domain-manager retourne les erreurs CAA dans son corps d'erreur.

Proxy Cloudflare activé. Voir étape 3 - le CNAME doit être DNS-only (nuage gris). Le mode orange-cloud (proxifié) réécrit le hostname dans la requête, ce qui cause l'échec de l'autorisation CaddyAsk.

Aplatissement CNAME à l'apex. L'aplatissement CNAME de Cloudflare fonctionne pour la plupart des cas d'usage mais a un effet subtil : la réponse DNS depuis les nameservers de Cloudflare est un enregistrement A (l'IP résolue), pas un CNAME. La vérification d'Elido utilise LookupCNAME, qui réussit quand les nameservers du fournisseur servent une réponse CNAME synthétisée. Si l'aplatissement de votre fournisseur DNS ne sert que l'enregistrement A final et aucun CNAME, la vérification CNAME ne passera pas. En pratique, l'aplatissement de Cloudflare inclut le CNAME dans la chaîne de réponse pour les enregistrements non-apex ; à l'apex, cela dépend de l'implémentation du fournisseur. Testez avec dig CNAME go.example.com depuis un resolver standard avant de conclure qu'il y a un bug.

Le TLS wildcard est HTTP-01, pas DNS-01. Elido n'émet pas de certificats wildcard (*.go.example.com) via le flux automatisé standard - selon RFC 8555 §8.4, les certificats wildcard exigent un challenge DNS-01, qui exige un accès en écriture à la zone DNS. Elido ne contrôle pas votre zone DNS. La fonctionnalité de domaine wildcard sur le forfait Business signifie qu'un seul CNAME couvre le routage pour tous les sous-domaines, mais chaque hostname (client1.go.example.com, client2.go.example.com) obtient son propre certificat émis via HTTP-01 à la première requête - pas un seul certificat wildcard. Le résultat opérationnel est le même : les sous-domaines fonctionnent automatiquement. Le magasin de certificats grandit proportionnellement.

Suppression du CNAME après vérification. Si votre équipe DNS supprime le CNAME pendant une migration ou un nettoyage, le check de santé périodique de domain-manager détectera l'enregistrement manquant et déplacera le domaine en statut degraded. Vous recevez une notification ; il y a un délai de grâce avant que le domaine ne soit suspendu. Restaurez le CNAME et le check de santé déplacera le domaine de retour vers actif automatiquement.

Comment cela diffère de Bitly et Rebrandly#

La configuration de domaine personnalisé de Bitly vous oblige à téléverser un certificat TLS ou utiliser leur flux de certificat géré, qui implique une étape manuelle de demande de certificat dans les paliers de forfait plus anciens. Le niveau d'automatisation dépend de votre forfait Bitly ; les comptes enterprise obtiennent un chemin plus géré.

Le processus de configuration de Rebrandly est poli - leur wizard d'onboarding fournit des instructions CNAME spécifiques au fournisseur et valide la propagation dans le navigateur. Le mécanisme TLS sous-jacent est fronté par CloudFront : Rebrandly utilise la fonctionnalité de domaine personnalisé d'AWS CloudFront, ce qui signifie que l'autorité de certification et le cycle de vie du certificat sont gérés par l'ACM d'Amazon. Cela fonctionne bien, mais cela signifie que votre trafic de domaine personnalisé route à travers l'infrastructure AWS US-East par défaut, ce qui est pertinent si vous évaluez la résidence des données UE (voir Elido vs Rebrandly pour la comparaison complète de résidence).

L'approche d'Elido - TLS à la demande de Caddy avec une barrière d'autorisation domain-manager - garde le cycle de vie complet du certificat en interne, fonctionne identiquement pour les déploiements auto-hébergés, et ne crée pas de dépendance sur un CDN tiers pour la gestion du certificat. Le coût de latence de première requête (2-3 secondes pour le challenge ACME) est le compromis ; les requêtes suivantes ne portent aucun surcoût.

Une fois la vérification complétée, créez un lien sous votre domaine personnalisé en passant domain_id dans l'appel de création de lien - ou sélectionnez-le depuis le sélecteur de domaine dans le tableau de bord ou l'app mobile. Le lien est immédiatement live à https://go.example.com/<slug> avec un certificat valide.

Lecture complémentaire : Liens courts à domaine personnalisé : DNS, TLS et ce qui tourne à l'edge couvre l'architecture complète y compris la mécanique du cache edge, les limites de taux et les modes d'échec en production. Le guide complet de configuration de domaine y compris les recommandations CAA et la référence API est à /docs/guides/custom-domains.

Marius Voß est DevRel + edge infra chez Elido. Il possède les services edge-redirect et domain-manager.

En lien sur le blog#

• Atteindre p95 < 15ms pour les redirections depuis FRA, ASH et SGP
• Configurer des liens courts brandés : choisir un domaine, livrer en un après-midi
• Deep links pour applications mobiles sans SDK
• Résidence des données UE pour les outils marketing : ce que votre DPO demande vraiment