Wie Sie in 5 Minuten eine eigene Domain mit TLS einrichten (mit Elido)

Die Einrichtung einer eigenen Domain mit HTTPS erfordert zwei DNS-Einträge und etwa drei Minuten Wartezeit auf die Propagation. Die restliche Zeit wird meist darauf verwendet, zu verstehen, was die Einträge bedeuten, warum beide benötigt werden und was passiert, nachdem man sie hinzugefügt hat. Dieser Post ist die praxisnahe Version: fünf konkrete Schritte, der exakte API-Aufruf und eine Erklärung der Zertifikatsmechanik, damit Sie wissen, was zu tun ist, wenn etwas schiefgeht.

Warum TLS speziell für Kurzlinks wichtig ist#

Ein Kurzlink ohne HTTPS ist in einer Weise ein Risiko, wie es ein normaler URL ohne HTTPS nicht ist.

Die Redirect-Antwort – ein 301 oder 302 mit einem Location-Header – ist die gesamte Nutzlast. Wenn die initiale HTTP-Anfrage über einfaches HTTP erfolgt, kann jeder auf dem Netzwerkpfad die Ziel-URL lesen, bevor der Client ihr folgt. Das bedeutet, dass Ihr Kampagnenziel, Ihre Affiliate-URL oder Ihr Link zu einem internen Tool für jeden Netzwerkbeobachter beim ersten Hop sichtbar ist. Moderne Browser haben damit begonnen, Sicherheitswarnungen für HTTP-Kurzlinks anzuzeigen, eben wegen dieses Expositionsmusters.

QR-Codes verschärfen das Problem. Eine Person, die einen Code im physischen Raum scannt, hat keine vorherige Beziehung zur URL – der Code ist das gesamte Vertrauenssignal. Eine Browser-Warnung beim ersten Laden ist der schlimmste denkbare Reibungspunkt: Sie haben bereits für den Druck, die Platzierung auf dem Event oder das OOH-Medium bezahlt, und eine Sicherheitswarnung beim Scannen ist das, was neugierige Personen am ehesten abschreckt. Ein gültiges TLS-Zertifikat unter Ihrer eigenen Domain ist das günstigste Vertrauenssignal, das Sie für eine QR-basierte Kampagne kaufen können.

Auf s.elido.me oder b.elido.me gehört das TLS-Zertifikat Elido. Das Vorhängeschloss ist echt, aber die Domain gehört nicht Ihnen, was bedeutet, dass das Markenvertrauen der Plattform zugutekommt, nicht Ihnen. Eine eigene Domain unter go.acme.com setzt Ihren Namen auf das Zertifikat.

Mehr zu den DNS- und TLS-Grundlagen im Cornerstone-Post: Custom domain short links: DNS, TLS, and what runs at the edge.

Schritt 1: Wählen Sie den Hostnamen#

Die häufigste Wahl ist eine kurze Subdomain Ihrer Hauptdomain: go.example.com, links.example.com oder s.example.com. Kurz ist besser – das Subdomain-Präfix erscheint in jedem Link, den Sie versenden.

Zwei Einschränkungen, die Sie vor Ihrer Entscheidung kennen sollten:

Nur Subdomains, es sei denn, Ihr DNS-Provider unterstützt ALIAS-Records. RFC 1034 §3.6.2 verbietet CNAME-Records am Zone Apex (example.com). Wenn Sie möchten, dass der nackte Apex weiterleitet, muss Ihr DNS-Provider ALIAS- oder ANAME-Records unterstützen (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS). Dies sind nicht-standardisierte Erweiterungen, die den Lookup „flachklopfen“, bevor sie ihn veröffentlichen. Prüfen Sie die Dokumentation Ihres Providers; der Name der Funktion variiert und nicht jeder Provider bietet sie an.

Wählen Sie eine Subdomain, die Sie für nichts anderes verwenden. Wenn links.example.com über Elido weitergeleitet wird, darf sie nicht gleichzeitig einen A-Record haben, der auf Ihren Webserver zeigt, oder einen bestehenden CNAME. DNS-Einträge für denselben Namen müssen konsistent sein.

Für die meisten Teams ist go.example.com oder links.example.com völlig in Ordnung. Wählen Sie einen Hostnamen, notieren Sie ihn und fahren Sie mit Schritt 2 fort.

Schritt 2: Registrieren Sie die Domain in Elido#

Öffnen Sie Settings → Custom Domains → Add Domain im Dashboard, geben Sie Ihren Hostnamen ein und klicken Sie auf Add. Die Antwort enthält zwei DNS-Eintragswerte: einen Verifizierungstoken und das CNAME-Ziel. Beides werden Sie in Schritt 3 verwenden.

Wenn Sie dies skripten – zum Beispiel beim Onboarding eines neuen Client-Workspace, als Teil einer Deploy-Pipeline oder bei der Verwaltung mit dem Terraform-Provider – lautet der API-Aufruf:

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

Der Response-Body enthält einen verification_token (einen zufälligen Hex-String) und instructions mit den exakten DNS-Eintragswerten:

{
  "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"
  }
}

Eigene Domains sind in den kostenpflichtigen Tarifen verfügbar. Der Business-Plan ist der Einstiegspunkt für eigene Domains; Agenturen, die mehrere Kundendomains unter einer Organisation verwalten, sollten sich das Workspace-Modell auf der Agentur-Lösungsseite ansehen.

Schritt 3: Fügen Sie die zwei DNS-Einträge hinzu#

Gehen Sie zum Control Panel Ihres DNS-Providers und fügen Sie beide Einträge aus dem instructions-Objekt hinzu. Sie benötigen beide – der CNAME leitet den Traffic zum Edge-Netzwerk von Elido weiter; der TXT-Record beweist, dass Sie die Domain besitzen, bevor Elido zustimmt, sie zu bedienen.

Für eine normale Subdomain:

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

Für eine Wildcard-Domain (Business-Plan, deckt *.go.example.com ab):

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

Das Präfix _elido-verify ist eine Standardkonvention für DNS-Challenges – es platziert den Eigentumsnachweis bei einer Subdomain des zu verifizierenden Hostnamens, sodass der TXT-Record nicht mit dem CNAME kollidieren kann.

Ein paar provider-spezifische Hinweise:

Cloudflare: Fügen Sie beide Einträge hinzu. Lassen Sie den CNAME-Proxy-Schalter aus (graue Wolke, DNS-only). Der HTTP-Proxy von Cloudflare entfernt den ursprünglichen Hostnamen, bevor er das Edge-Netzwerk von Elido erreicht, was die CaddyAsk-Autorisierungsprüfung unterbricht. Der DNS-only-Modus leitet die Anfrage unverändert weiter.
AWS Route 53: Verwenden Sie einen ALIAS-Record, wenn Sie den Apex benötigen; für Subdomains ist ein normaler CNAME korrekt. Route 53 unterstützt keinen CNAME am Zone Apex, unterstützt aber ALIAS auf externe Ziele.
GoDaddy / Namecheap / die meisten Registrar-DNS: Standard CNAME und TXT – keine spezielle Konfiguration erforderlich.

Stellen Sie die TTL beider Einträge auf 300 Sekunden (5 Minuten) ein, wenn Ihr Provider dies zulässt. Die Standard-TTL für viele verwaltete Zonen beträgt 3600 Sekunden; eine kürzere TTL bedeutet eine schnellere Bestätigung der Propagation und eine schnellere Wiederherstellung, falls Sie die Einträge später ändern müssen.

Der CNAME-Eintrag zeigt go.example.com auf edge.elido.me, um den Traffic weiterzuleiten; der TXT-Eintrag bei _elido-verify beweist die Zonenzugehörigkeit, bevor domain-manager die Domain als verifiziert markiert.

Schritt 4: Warten Sie auf die Verifizierung#

Sobald die Einträge vorhanden sind, fragt domain-manager diese automatisch über den öffentlichen Resolver von Google (8.8.8.8) in kurzen Intervallen ab. Sie müssen nicht auf „Jetzt verifizieren“ klicken.

Der Service prüft zwei Bedingungen, bevor er die Domain als aktiv markiert:

_elido-verify.go.example.com gibt einen TXT-Record zurück, dessen Wert verify=<token> ist – dies bestätigt, dass Sie die DNS-Zone kontrollieren.
go.example.com wird via CNAME auf edge.elido.me aufgelöst – dies bestätigt, dass der Traffic das Edge-Netzwerk von Elido erreicht.

Wenn beide Prüfungen erfolgreich sind, wechselt der status von pending_verification zu verified. Sie können dies selbst abfragen:

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

Beobachten Sie das Feld status. Die typische Propagationszeit für Einträge mit einer TTL von 300s liegt unter 5 Minuten. Einträge mit der Standard-TTL von 3600s können bis zu einer Stunde dauern, wenn Sie sich in einem Teil der Welt befinden, in dem Resolver beim Caching aggressiv sind.

Wenn die Verifizierung stockt, prüfen Sie, ob Ihre Einträge korrekt veröffentlicht wurden:

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

Der TXT-Lookup sollte "verify=<your-token>" zurückgeben. Der CNAME-Lookup sollte edge.elido.me. zurückgeben (der abschließende Punkt ist normal).

Schritt 5: Die erste Anfrage stellt das Zertifikat automatisch aus#

Sobald domain-manager die Domain als verifiziert markiert und bei Caddy registriert hat, sind Sie auf Ihrer Seite fertig. TLS geschieht ohne weiteres Zutun.

Der Mechanismus ist das On-Demand TLS von Caddy (ADR-0012): Anstatt Zertifikate für jede verifizierte Domain vorab auszustellen, stellt Caddy das Zertifikat beim ersten TLS-Handshake für einen neuen Hostnamen aus. Bevor Caddy eine ACME-Ausstellung versucht, ruft es den CaddyAsk-Endpunkt von domain-manager auf – ein einfacher HTTP-GET ?domain=go.example.com. Wenn domain-manager 200 zurückgibt (die Domain ist im Status „verified“ oder „active“), fährt Caddy fort. Wenn er 404 zurückgibt, schlägt der TLS-Handshake fehl und es wird kein Zertifikat angefordert. Diese Schranke ist die letzte Verteidigungslinie gegen die fehlerhafte Ausstellung von Zertifikaten für unbekannte Hostnamen.

Wenn Caddy fortfährt, führt der ACME-Flow (RFC 8555) eine HTTP-01-Challenge aus:

Caddy fordert eine neue Order bei Let's Encrypt an.
Let's Encrypt antwortet mit einem Challenge-Token: Platzieren Sie diesen unter http://go.example.com/.well-known/acme-challenge/<token>.
Caddy platziert den Token in seinem In-Memory-HTTP-Handler.
Let's Encrypt ruft den Token über einfaches HTTP ab und validiert ihn.
Das Zertifikat wird ausgestellt, im Zertifikatscache von Caddy gespeichert und die ursprüngliche HTTPS-Anfrage wird bedient.

Die Schritte 1–5 fügen der allerersten Anfrage an eine neu verifizierte Domain etwa 2–3 Sekunden Latenz hinzu. Jede nachfolgende Anfrage verwendet das im Cache gespeicherte Zertifikat ohne Overhead. Caddy übernimmt die Erneuerung automatisch vor Ablauf der Gültigkeit.

Elido stellt ECDSA P-256-Zertifikate für alle eigenen Domains aus. P-256-Signaturen sind kleiner und schneller zu verifizieren als RSA-2048, was am Edge wichtig ist, wo TLS-Handshakes im kritischen Pfad liegen.

Beim ersten TLS-Handshake ruft Caddy die CaddyAsk-Schranke auf; ein 404 stoppt die Zertifikatsausstellung, während ein 200 für eine verifizierte Domain zur Let's Encrypt HTTP-01-Challenge und einem gecachten ECDSA P-256-Zertifikat führt.

Häufige Stolperfallen#

CAA-Einträge blockieren Let's Encrypt. Certification Authority Authorization (CAA) Einträge legen fest, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. Wenn Ihre DNS-Zone example.com CAA 0 issue "digicert.com" enthält, wird Let's Encrypt die Ausstellung eines Zertifikats für go.example.com verweigern, da diese die CAA-Policy des Apex erbt. Die Lösung: Fügen Sie go.example.com CAA 0 issue "letsencrypt.org" hinzu oder entfernen Sie die Apex-Beschränkung, sofern Ihre Sicherheitsrichtlinie dies zulässt. Der Status-Endpunkt von domain-manager gibt CAA-Fehler im Error-Body zurück.

Cloudflare-Proxy aktiviert. Siehe Schritt 3 – der CNAME muss auf „DNS-only“ (graue Wolke) stehen. Der „Proxied“-Modus (orangefarbene Wolke) schreibt den Hostnamen in der Anfrage um, was dazu führt, dass die CaddyAsk-Autorisierung fehlschlägt.

CNAME-Flattening am Apex. Das CNAME-Flattening von Cloudflare funktioniert für die meisten Anwendungsfälle, hat aber einen subtilen Effekt: Die DNS-Antwort von den Nameservern von Cloudflare ist ein A-Record (die aufgelöste IP), kein CNAME. Die Verifizierungsprüfung von Elido verwendet LookupCNAME, was erfolgreich ist, wenn die Nameserver des Providers eine synthetisierte CNAME-Antwort liefern. Wenn das Flattening Ihres DNS-Providers nur den finalen A-Record und keinen CNAME liefert, wird die CNAME-Prüfung nicht bestanden. In der Praxis schließt das Flattening von Cloudflare den CNAME in die Antwortkette für Non-Apex-Records ein; am Apex hängt es von der Implementierung des Providers ab. Testen Sie mit dig CNAME go.example.com über einen Standard-Resolver, bevor Sie auf einen Fehler schließen.

Wildcard-TLS ist HTTP-01, nicht DNS-01. Elido stellt keine Wildcard-Zertifikate (*.go.example.com) über den standardmäßigen automatisierten Flow aus – gemäß RFC 8555 §8.4 erfordern Wildcard-Zertifikate eine DNS-01-Challenge, die Schreibzugriff auf die DNS-Zone voraussetzt. Elido kontrolliert Ihre DNS-Zone nicht. Die Wildcard-Domain-Funktion im Business-Plan bedeutet, dass ein CNAME das Routing für alle Subdomains abdeckt, aber jeder Hostname (client1.go.example.com, client2.go.example.com) erhält sein eigenes Zertifikat, das bei der ersten Anfrage via HTTP-01 ausgestellt wird – kein einzelnes Wildcard-Zertifikat. Das operative Ergebnis ist dasselbe: Subdomains funktionieren automatisch. Der Zertifikatsspeicher wächst proportional.

Löschen des CNAME nach der Verifizierung. Wenn Ihr DNS-Team den CNAME während einer Migration oder Bereinigung entfernt, erkennt der periodische Health-Check von domain-manager den fehlenden Eintrag und verschiebt die Domain in den Status degraded. Sie erhalten eine Benachrichtigung; es gibt eine Kulanzzeit, bevor die Domain suspendiert wird. Stellen Sie den CNAME wieder her, und der Health-Check wird die Domain automatisch wieder auf „aktiv“ setzen.

Wie sich dies von Bitly und Rebrandly unterscheidet#

Das Setup für eigene Domains bei Bitly erfordert das Hochladen eines TLS-Zertifikats oder die Nutzung ihres verwalteten Zertifikats-Flows, was in älteren Tarifen einen manuellen Schritt zur Zertifikatsanforderung beinhaltet. Der Automatisierungsgrad hängt von Ihrem Bitly-Tarif ab; Enterprise-Accounts erhalten einen stärker verwalteten Pfad.

Der Einrichtungsprozess von Rebrandly ist ausgefeilt – ihr Onboarding-Assistent bietet provider-spezifische CNAME-Anleitungen und validiert die Propagation direkt im Browser. Der zugrunde liegende TLS-Mechanismus basiert auf CloudFront: Rebrandly nutzt die Custom-Domain-Funktion von AWS CloudFront, was bedeutet, dass die Zertifizierungsstelle und der Zertifikats-Lebenszyklus von AWS ACM verwaltet werden. Das funktioniert gut, bedeutet aber auch, dass der Traffic Ihrer eigenen Domain standardmäßig über die AWS-Infrastruktur in US-East geleitet wird, was relevant ist, wenn Sie die EU-Datenresidenz bewerten (siehe Elido vs Rebrandly für den vollständigen Vergleich zur Residenz).

Der Ansatz von Elido – Caddy On-Demand TLS mit einer Autorisierungsschranke durch domain-manager – behält den gesamten Zertifikats-Lebenszyklus im Haus, funktioniert identisch für Self-Hosted-Deployments und schafft keine Abhängigkeit von einem Drittanbieter-CDN für die Zertifikatsverwaltung. Die Latenzkosten bei der ersten Anfrage (2–3s für die ACME-Challenge) sind der Kompromiss; nachfolgende Anfragen haben keinen Overhead.

Eine Matrix, die Elido, Bitly und Rebrandly nach Zertifikatsauslöser, Zertifizierungsstelle, Drittanbieter-CDN-Abhängigkeit, Self-Hosting-Parität und EU-Datenresidenz standardmäßig vergleicht.

Sobald die Verifizierung abgeschlossen ist, erstellen Sie einen Link unter Ihrer eigenen Domain, indem Sie die domain_id beim Aufruf zur Link-Erstellung übergeben – oder wählen Sie sie über den Domain-Picker im Dashboard oder in der mobilen App aus. Der Link ist sofort unter https://go.example.com/<slug> mit einem gültigen Zertifikat live.

Weiterführende Informationen: Custom domain short links: DNS, TLS, and what runs at the edge behandelt die vollständige Architektur inklusive Edge-Cache-Mechanik, Ratenbegrenzungen und Produktions-Fehlermodi. Den vollständigen Leitfaden zur Domain-Konfiguration inklusive CAA-Empfehlungen und der API-Referenz finden Sie unter /docs/guides/custom-domains.

Marius Voß ist DevRel + edge infra bei Elido. Er verantwortet die Services edge-redirect und domain-manager.

Passende Blogartikel#

Elido testen

URL einfügen, kurzer Link in Sekunden

Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.

Kostenlos, keine Anmeldung erforderlich · 2 pro Tag