TLS pour domaine personnalisé et liens courts : en 5 minutes

Configurer un domaine personnalisé avec HTTPS demande un enregistrement TXT, un enregistrement CNAME et une courte attente. Vous ajoutez le nom d'hôte dans Elido, copiez les deux valeurs DNS qu'il vous donne, et le certificat TLS est émis automatiquement la première fois que quelqu'un ouvre un lien sur ce domaine. La partie lente est la propagation DNS, que vous contrôlez avec le TTL. Cet article parcourt les cinq étapes, puis explique la mécanique pour que vous sachiez où regarder quand une étape cale.

Tout ce qui suit a été vérifié le 2026-10-09 par rapport au code et au tableau de bord actuels d'Elido. Quand une fonctionnalité connexe n'est pas encore construite, l'article le dit.

Pourquoi le TLS compte sur un lien court

Un lien court est une redirection, et la réponse de redirection est toute la charge utile. Un 301 ou 302 avec un en-tête Location porte votre URL de destination. Si la première requête circule en HTTP simple, toute personne sur le chemin réseau peut lire cette destination avant que le navigateur ne la suive.

Les QR codes aggravent la situation. Quelqu'un qui scanne un code sur une vitrine ou une affiche n'a aucune relation préalable avec l'URL : la barre d'adresse est donc son seul signal de confiance. Un avertissement du navigateur au scan est la pire première impression possible, et vous avez déjà payé le tirage.

Sur les domaines courts partagés d'Elido, le certificat appartient à Elido : le cadenas est donc réel, mais le nom qui y figure n'est pas le vôtre. Sur go.acme.com, le nom est le vôtre. Pour les fondamentaux DNS et TLS qui sous-tendent cela, voir l'article de référence sur les liens courts à domaine personnalisé.

Étape 1 : choisir le nom d'hôte

Choisissez un sous-domaine court que vous contrôlez et que vous n'utilisez pour rien d'autre : go.example.com, links.example.com ou similaire. Le préfixe apparaît dans chaque lien que vous envoyez : plus il est court, mieux c'est.

Utilisez un sous-domaine, pas la racine nue. La RFC 1034 section 3.6.2 dit qu'un nom portant un CNAME ne peut contenir aucune autre donnée, et que la racine d'une zone contient toujours des enregistrements SOA et NS : un CNAME y est donc interdit. Certains fournisseurs DNS le simulent avec des enregistrements ALIAS ou aplatis, mais ceux-ci répondent avec des adresses IP au lieu d'un CNAME. La vérification d'Elido demande le CNAME lui-même : une racine aplatie ne passera donc pas.

Deux règles de plus s'appliquent à l'enregistrement du nom. Le nom d'hôte doit être un nom de domaine complet (FQDN) en minuscules, et les noms sous elido.me ou elido.app sont réservés.

Étape 2 : ajouter le domaine dans Elido

Ouvrez Domains dans la barre latérale du tableau de bord, saisissez le nom d'hôte et cliquez sur Add domain. Cochez la case wildcard uniquement si vous voulez que tous les sous-domaines de ce nom fonctionnent, comme dans *.go.example.com. En général, ce n'est pas nécessaire. Elido affiche alors les deux enregistrements DNS, avec un bouton de copie à côté de chacun.

La même étape via l'API, pour des scripts d'intégration ou des espaces de travail clients :

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}'

L'appel exige un rôle autorisé à gérer les domaines. Un nouveau domaine revient avec le statut pending, un verify_token et un objet instructions contenant les valeurs exactes des enregistrements :

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

Les domaines personnalisés exigent une offre payante. Essayez d'en enregistrer un sur un espace de travail Free, au-delà du nombre de domaines de votre offre, ou sur un abonnement suspendu ou résilié, et l'API répond 402. C'est le code que je gérerais en premier dans tout script d'onboarding, car c'est celui qu'un client rencontre dès le premier jour. Un nom d'hôte en double reçoit 409. Les agences qui gèrent de nombreux domaines clients liront la page solutions pour agences pour le modèle d'espaces de travail.

Étape 3 : publier les deux enregistrements DNS

Ajoutez les deux enregistrements chez votre fournisseur DNS, exactement comme indiqué :

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

Le CNAME achemine le trafic vers Elido. L'enregistrement TXT prouve que vous possédez la zone. Les deux sont requis, et la valeur TXT doit correspondre exactement au token.

Pour un enregistrement wildcard, le CNAME devient *.go.example.com, tandis que l'enregistrement TXT reste à _elido-verify.go.example.com, sur le nom parent sans l'astérisque.

Fixez un TTL de 300 secondes sur les deux enregistrements si votre fournisseur le permet. Beaucoup de zones ont 3600 secondes par défaut, et un TTL long transforme un travail de cinq minutes en une heure.

Une remarque sur les fournisseurs compte plus que les autres. Si vous utilisez Cloudflare, laissez le CNAME en DNS seul (DNS-only). La documentation de Cloudflare indique qu'un enregistrement proxifié reçoit en réponse les propres adresses IP de Cloudflare au lieu du contenu de l'enregistrement (consultée le 2026-10-09). Un nom proxifié ne renvoie donc jamais le CNAME qu'Elido cherche, et la vérification ne passera pas.

Étape 4 : attendre la vérification

Vous n'avez rien à cliquer. Un worker en arrière-plan dans l'API d'Elido vérifie chaque domaine en attente selon une minuterie, 30 secondes par défaut, en utilisant le résolveur public de Google à 8.8.8.8. Il ne valide le domaine que si les deux conditions sont réunies :

1. L'enregistrement TXT à _elido-verify.<hostname> contient exactement verify=<token>.
2. Le nom d'hôte a un CNAME qui se résout vers la cible edge d'Elido.

Quand les deux passent, le statut devient verified. Interrogez-le vous-même si vous scriptez la configuration :

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

Pour sauter l'attente du prochain cycle, envoyez POST .../domains/42/verify. Il renvoie 202 et place le domaine en tête de la file. Un domaine qui reste en attente pendant 24 heures est marqué failed avec le motif « verification timeout », et le même appel verify remet un domaine en échec à l'état pending pour que vous puissiez réessayer après avoir corrigé le DNS.

Si cela cale, interrogez les enregistrements comme le fait le vérificateur :

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

Le premier doit afficher "verify=<your-token>". Le second doit afficher edge.elido.me., point final compris.

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

Dès que le statut est verified, il ne vous reste rien à faire. Elido n'émet pas de certificats à l'avance. La couche TLS en émet un à la demande, la première fois qu'un navigateur ouvre une connexion TLS pour votre nom d'hôte.

Avant de demander quoi que ce soit à Let's Encrypt, l'edge appelle un contrôle d'autorisation sur l'API d'Elido. La réponse n'est oui que si le nom d'hôte est à l'état verified ou active, ou s'il relève d'un enregistrement wildcard vérifié. Toute autre réponse, y compris pour un nom inconnu, refuse le handshake et aucun certificat n'est demandé. Cette barrière empêche un inconnu de pointer un million de noms d'hôte vers Elido et d'épuiser les limites de débit de l'autorité de certification.

Quand le contrôle passe, l'émission utilise le challenge HTTP-01 de la RFC 8555 : l'autorité de certification demande un jeton à /.well-known/acme-challenge/ sur votre nom d'hôte en HTTP simple, l'edge y répond, et le certificat est émis puis mis en cache. Le premier visiteur patiente un instant. Les requêtes suivantes réutilisent le certificat en cache.

Une bonne habitude : ouvrez vous-même https://go.example.com juste après la vérification, pour que le certificat existe avant qu'un client ou un scan de QR code soit la première requête.

Passez l'id du domaine comme domain_id lorsque vous créez un lien. Le lien est en ligne à https://go.example.com/<slug> immédiatement. La page Domains affiche aussi les clics sur 30 jours par nom d'hôte. La référence complète, y compris les conseils sur CAA, se trouve dans le guide des domaines personnalisés, et la présentation du produit sur la page de la fonctionnalité domaines personnalisés.

Ce que signifient les valeurs de statut

Dans la version actuelle, un domaine sain reste à verified. La valeur active existe dans le modèle de données et dans le filtre du tableau de bord, et la barrière de certificat accepte les deux, mais rien n'y fait passer un domaine pour l'instant.

Pièges courants

Des enregistrements CAA qui excluent Let's Encrypt. Un enregistrement CAA limite les autorités autorisées à émettre pour un nom, et il est hérité par les sous-domaines (consulté le 2026-10-09). Si votre zone contient example.com CAA 0 issue "digicert.com", l'émission pour go.example.com est refusée. Ajoutez go.example.com CAA 0 issue "letsencrypt.org" ou élargissez l'enregistrement de l'apex.

Un proxy ou un CDN devant le CNAME. Le nuage orange de Cloudflare est le cas habituel, traité à l'étape 3. Toute couche qui répond au DNS ou au HTTP en votre nom casse à la fois la vérification du CNAME et le challenge HTTP-01.

Les wildcards ne sont pas des certificats wildcard. Selon la documentation des challenges de Let's Encrypt, HTTP-01 ne peut pas émettre de certificats wildcard, et DNS-01 exige un accès en écriture à votre zone (consultée le 2026-10-09). Un enregistrement wildcard couvre donc le routage de chaque sous-domaine, mais client1.go.example.com et client2.go.example.com reçoivent chacun leur propre certificat à la première utilisation. Let's Encrypt limite les nouveaux certificats par domaine enregistré à 50 tous les 7 jours (consulté le 2026-10-09) : intégrer des centaines de nouveaux sous-domaines en une semaine demande donc de la planification.

Supprimer le CNAME plus tard. Aujourd'hui, la vérification DNS ne s'exécute que tant qu'un domaine est en attente. Une fois un domaine vérifié, Elido ne le revérifie pas : un CNAME supprimé se manifeste donc par des redirections et des renouvellements de certificat en échec, pas par un changement de statut ou une notification. Surveillez l'enregistrement de votre côté. Un contrôle de santé périodique avec un état dégradé et un délai de grâce est prévu, pas construit.

Marius Voß est DevRel + infrastructure edge chez Elido. Il est responsable du chemin de redirection et du flux des domaines personnalisés.

Voir aussi sur le blog

• Liens courts à domaine personnalisé : DNS, TLS et ce qui tourne à l'edge
• Configurer des liens courts personnalisés : choisir un domaine, livrer en une après-midi
• Tenir un p95 < 15 ms pour les redirections
• Elido vs Rebrandly
• Les raccourcisseurs d'URL nuisent-ils au SEO ?