Jak skonfigurować własną domenę z TLS w 5 minut (z Elido)

Skonfigurowanie własnej domeny z HTTPS wymaga dwóch rekordów DNS i około trzech minut oczekiwania na propagację. Reszta czasu jest zazwyczaj poświęcana na zrozumienie, co oznaczają te rekordy, dlaczego oba są potrzebne i co dzieje się po ich dodaniu. Ten artykuł to wersja praktyczna: pięć konkretnych kroków, dokładne wywołanie API i wyjaśnienie mechanizmu certyfikatów, abyś wiedział, co robić, gdy coś pójdzie nie tak.

Dlaczego TLS ma szczególne znaczenie dla krótkich linków#

Krótki link bez HTTPS jest ryzykiem w sposób, w jaki zwykły URL bez HTTPS nie jest.

Odpowiedź przekierowania - 301 lub 302 z nagłówkiem Location - to cały payload. Jeśli początkowe żądanie HTTP przechodzi przez zwykłe HTTP, każdy na ścieżce sieciowej może odczytać docelowy URL, zanim klient go otworzy. Oznacza to, że cel Twojej kampanii, adres URL partnera afiliacyjnego lub link do wewnętrznego narzędzia jest widoczny dla każdego obserwatora sieci na pierwszym skoku. Nowoczesne przeglądarki zaczęły wyświetlać ostrzeżenia bezpieczeństwa przy krótkich linkach HTTP właśnie z powodu tego wzorca ekspozycji.

Kody QR potęgują ten problem. Osoba skanująca kod w przestrzeni fizycznej nie ma żadnej wcześniejszej relacji z URL - kod jest jedynym sygnałem zaufania. Ostrzeżenie przeglądarki przy pierwszym załadowaniu jest najgorszym możliwym punktem tarcia: już zapłaciłeś za druk, miejsce na wydarzeniu lub media zewnętrzne, a ostrzeżenie bezpieczeństwa podczas skanowania to rzecz, która najskuteczniej odstrasza ciekawą osobę. Ważny certyfikat TLS pod Twoją własną domeną to najtańszy sygnał zaufania, jaki możesz kupić w kampanii opartej na kodach QR.

Na s.elido.me lub b.elido.me certyfikat TLS należy do Elido. Kłódka jest prawdziwa, ale domena nie jest Twoja, co oznacza, że zaufanie do marki trafia do platformy, nie do Ciebie. Własna domena pod go.acme.com umieszcza Twoje imię na certyfikacie.

Więcej na temat podstaw DNS i TLS znajdziesz w artykule cornerstone: Niestandardowe krótkie linki z własną domeną: DNS, TLS i co działa na edge.

---

Krok 1: Wybierz nazwę hosta#

Najczęstszym wyborem jest krótka subdomena Twojej głównej domeny: go.example.com, links.example.com lub s.example.com. Krótka jest lepsza - prefiks subdomeny pojawia się w każdym wysyłanym przez Ciebie linku.

Dwa ograniczenia, które warto poznać przed podjęciem decyzji:

Tylko subdomena, chyba że Twój dostawca DNS obsługuje rekordy ALIAS. RFC 1034 §3.6.2 zabrania rekordów CNAME w wierzchołku strefy (example.com). Jeśli chcesz, aby gołe apex przekierowywało, Twój dostawca DNS musi obsługiwać rekordy ALIAS lub ANAME (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS). Są to niestandardowe rozszerzenia, które spłaszczają wyszukiwanie przed jego opublikowaniem. Sprawdź dokumentację swojego dostawcy; nazwa funkcji jest różna i nie każdy dostawca ją oferuje.

Wybierz subdomenę, której nie używasz do niczego innego. links.example.com przekierowujące przez Elido nie może jednocześnie mieć rekordu A wskazującego na Twój serwer WWW ani istniejącego CNAME. Rekordy DNS dla tej samej nazwy muszą być spójne.

Dla większości zespołów: go.example.com lub links.example.com jest dobrym wyborem. Wybierz, zanotuj i przejdź do kroku 2.

---

Krok 2: Zarejestruj domenę w Elido#

Otwórz Ustawienia → Domeny niestandardowe → Dodaj domenę w panelu, wpisz swoją nazwę hosta i kliknij Dodaj. Odpowiedź zawiera dwie wartości rekordów DNS: token weryfikacyjny i cel CNAME. Oba użyjesz w kroku 3.

Jeśli skryptujesz to - wdrażasz nowy workspace klienta, uruchamiasz jako część pipeline'u deploymentu lub zarządzasz przy użyciu dostawcy Terraform - wywołanie API wygląda tak:

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

Treść odpowiedzi zawiera verification_token (losowy ciąg szesnastkowy) oraz instructions z dokładnymi wartościami rekordów 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"
  }
}

Domeny niestandardowe są dostępne w płatnych planach. Plan Business to punkt wejścia dla domen niestandardowych; agencje zarządzające wieloma domenami klientów w ramach jednej organizacji powinny zapoznać się z modelem workspace na stronie rozwiązań dla agencji.

---

Krok 3: Dodaj dwa rekordy DNS#

Przejdź do panelu sterowania swojego dostawcy DNS i dodaj oba rekordy z obiektu instructions. Potrzebujesz obu - CNAME kieruje ruch do edge Elido; rekord TXT udowadnia, że jesteś właścicielem domeny, zanim Elido zgodzi się ją obsługiwać.

Dla zwykłej subdomeny:

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

Dla domeny wildcard (plan Business, obejmuje *.go.example.com):

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

Prefiks _elido-verify to standardowa konwencja DNS challenge - umieszcza dowód własności w subdomenie weryfikowanej nazwy hosta, aby rekord TXT nie kolidował z CNAME.

Kilka uwag dotyczących konkretnych dostawców:

• Cloudflare: Dodaj oba rekordy. Pozostaw przełącznik proxy CNAME wyłączony (szara chmurka, tylko DNS). Proxy HTTP Cloudflare przepisuje oryginalną nazwę hosta przed dotarciem do edge Elido, co łamie autoryzację CaddyAsk. Tryb DNS-only przekazuje żądanie bez modyfikacji.
• AWS Route 53: Użyj rekordu ALIAS, jeśli potrzebujesz apex; dla subdomen zwykły CNAME jest poprawny. Route 53 nie obsługuje CNAME w wierzchołku strefy, ale obsługuje ALIAS do zewnętrznych celów.
• GoDaddy / Namecheap / większość DNS rejestratorów: Standardowy CNAME i TXT - bez specjalnej konfiguracji.

Ustaw TTL obu rekordów na 300 sekund (5 minut), jeśli Twój dostawca na to pozwala. Domyślne TTL dla wielu zarządzanych stref to 3600 sekund; krótsze TTL oznacza szybsze potwierdzenie propagacji i szybszą naprawę, jeśli będziesz musiał później zmienić rekordy.

---

Krok 4: Poczekaj na weryfikację#

Gdy rekordy są już na miejscu, domain-manager automatycznie sonduje je przy użyciu publicznego resolwera Google (8.8.8.8) w krótkich odstępach czasu. Nie musisz klikać "Zweryfikuj teraz".

Usługa sprawdza dwa warunki przed oznaczeniem domeny jako aktywnej:

1. _elido-verify.go.example.com zwraca rekord TXT, którego wartość to verify=<token> - to potwierdza, że kontrolujesz strefę DNS.
2. go.example.com rozwiązuje się przez CNAME do edge.elido.me - to potwierdza, że ruch dotrze do edge Elido.

Gdy oba warunki zostaną spełnione, status przechodzi z pending_verification na verified. Możesz samodzielnie odpytywać ten status:

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

Obserwuj pole status. Typowy czas propagacji dla rekordów ustawionych z TTL 300s wynosi poniżej 5 minut. Rekordy z domyślnym TTL 3600s mogą trwać do godziny, jeśli jesteś w części świata, gdzie resolvery agresywnie buforują.

Jeśli weryfikacja utknęła, sprawdź, czy Twoje rekordy są poprawnie opublikowane:

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

Wyszukiwanie TXT powinno zwrócić "verify=<your-token>". Wyszukiwanie CNAME powinno zwrócić edge.elido.me. (końcowa kropka jest normalna).

---

Krok 5: Pierwsze żądanie automatycznie wystawia certyfikat#

Gdy domain-manager oznaczy domenę jako zweryfikowaną i zarejestruje ją w Caddy, Twoja część jest gotowa. TLS odbywa się bez żadnych dalszych działań.

Mechanizmem jest Caddy on-demand TLS (ADR-0012): zamiast wcześniej wystawiać certyfikaty dla każdej zweryfikowanej domeny, Caddy wystawia certyfikat przy pierwszym TLS handshake dla nowej nazwy hosta. Przed próbą wystawienia ACME, Caddy wywołuje endpoint CaddyAsk serwisu domain-manager - zwykłe żądanie HTTP GET ?domain=go.example.com. Jeśli domain-manager zwróci 200 (domena jest w stanie verified lub active), Caddy kontynuuje. Jeśli zwróci 404, TLS handshake kończy się niepowodzeniem i żaden certyfikat nie jest nigdy żądany. Ta bramka to ostatnia linia obrony przed błędnym wystawianiem certyfikatów dla nierozpoznanych nazw hostów.

Gdy Caddy kontynuuje, przepływ ACME (RFC 8555) wykonuje wyzwanie HTTP-01:

1. Caddy żąda nowego zamówienia od Let's Encrypt.
2. Let's Encrypt odpowiada tokenem wyzwania: umieść go pod adresem http://go.example.com/.well-known/acme-challenge/<token>.
3. Caddy umieszcza token w swoim wewnętrznym handlerze HTTP.
4. Let's Encrypt pobiera token przez zwykłe HTTP i waliduje go.
5. Certyfikat jest wystawiony, zapisany w cache certyfikatów Caddy, a oryginalne żądanie HTTPS jest obsługiwane.

Kroki 1–5 dodają około 2–3 sekundy latencji do pierwszego żądania do nowo zweryfikowanej domeny. Każde kolejne żądanie używa zbuforowanego certyfikatu bez żadnych opóźnień. Caddy obsługuje odnawianie automatycznie przed wygaśnięciem.

Elido wystawia certyfikaty ECDSA P-256 dla wszystkich domen niestandardowych. Podpisy P-256 są mniejsze i szybsze do weryfikacji niż RSA-2048, co ma znaczenie na edge, gdzie TLS handshake leży na gorącej ścieżce.

---

Typowe pułapki#

Rekordy CAA blokujące Let's Encrypt. Rekordy Certification Authority Authorization (CAA) określają, które urzędy certyfikacji są upoważnione do wystawiania certyfikatów dla domeny. Jeśli Twoja strefa DNS zawiera example.com CAA 0 issue "digicert.com", Let's Encrypt odmówi wystawienia certyfikatu dla go.example.com, ponieważ dziedziczy politykę CAA apex. Rozwiązanie: dodaj go.example.com CAA 0 issue "letsencrypt.org" lub usuń ograniczenie apex, jeśli Twoja polityka bezpieczeństwa na to pozwala. Endpoint statusu domain-manager zwraca błędy CAA w treści błędu.

Włączone proxy Cloudflare. Patrz krok 3 - CNAME musi być tylko DNS (szara chmurka). Tryb orange-cloud (proxied) przepisuje nazwę hosta w żądaniu, co powoduje niepowodzenie autoryzacji CaddyAsk.

Spłaszczanie CNAME w apex. Spłaszczanie CNAME Cloudflare działa w większości przypadków użycia, ale ma jeden subtelny efekt: odpowiedź DNS z serwerów nazw Cloudflare to rekord A (rozwiązany IP), nie CNAME. Weryfikacja Elido używa LookupCNAME, która kończy się sukcesem, gdy serwery nazw dostawcy zwracają syntetyczną odpowiedź CNAME. Jeśli spłaszczanie Twojego dostawcy DNS zwraca tylko końcowy rekord A bez CNAME, sprawdzenie CNAME nie przejdzie. W praktyce spłaszczanie Cloudflare dołącza CNAME do łańcucha odpowiedzi dla rekordów nie-apex; w apex zależy to od implementacji dostawcy. Przetestuj za pomocą dig CNAME go.example.com ze standardowego resolwera przed stwierdzeniem, że to błąd.

Wildcard TLS to HTTP-01, nie DNS-01. Elido nie wystawia certyfikatów wildcard (*.go.example.com) przez standardowy zautomatyzowany przepływ - zgodnie z RFC 8555 §8.4, certyfikaty wildcard wymagają wyzwania DNS-01, które wymaga dostępu do zapisu w strefie DNS. Elido nie kontroluje Twojej strefy DNS. Funkcja domeny wildcard w planie Business oznacza, że jeden CNAME pokrywa routing dla wszystkich subdomen, ale każda nazwa hosta (client1.go.example.com, client2.go.example.com) otrzymuje własny certyfikat wystawiony przez HTTP-01 przy pierwszym żądaniu - nie jeden certyfikat wildcard. Wynik operacyjny jest taki sam: subdomeny działają automatycznie. Magazyn certyfikatów rośnie proporcjonalnie.

Usuwanie CNAME po weryfikacji. Jeśli Twój zespół DNS usunie CNAME podczas migracji lub porządkowania, okresowe sprawdzenie kondycji domain-manager wykryje brakujący rekord i przeniesie domenę do statusu degraded. Otrzymasz powiadomienie; jest okres karencji przed zawieszeniem domeny. Przywróć CNAME, a sprawdzenie kondycji automatycznie przywróci domenę do stanu aktywnego.

---

Jak to różni się od Bitly i Rebrandly#

Konfiguracja domeny niestandardowej w Bitly wymaga przesłania certyfikatu TLS lub skorzystania z ich zarządzanego przepływu certyfikatów, który obejmuje ręczny krok żądania certyfikatu w starszych tierach planów. Poziom automatyzacji zależy od Twojego planu Bitly; konta enterprise mają bardziej zarządzaną ścieżkę.

Proces konfiguracji Rebrandly jest dopracowany - ich wizard onboardingowy dostarcza instrukcji CNAME specyficznych dla dostawcy i waliduje propagację w przeglądarce. Podstawowy mechanizm TLS jest fronted przez CloudFront: Rebrandly używa funkcji domeny niestandardowej AWS CloudFront, co oznacza, że urząd certyfikacji i cykl życia certyfikatu są zarządzane przez Amazon ACM. To działa dobrze, ale oznacza, że ruch do Twojej domeny niestandardowej domyślnie przechodzi przez infrastrukturę AWS US-East, co jest istotne, jeśli oceniasz rezydencję danych w UE (patrz Elido vs Rebrandly, aby zobaczyć pełne porównanie rezydencji).

Podejście Elido - Caddy on-demand TLS z bramką autoryzacji domain-manager - utrzymuje pełny cykl życia certyfikatu wewnętrznie, działa identycznie dla samodzielnie hostowanych wdrożeń i nie tworzy zależności od żadnej zewnętrznej sieci CDN do zarządzania certyfikatami. Koszt latencji pierwszego żądania (2–3s dla wyzwania ACME) to kompromis; kolejne żądania nie mają żadnych dodatkowych opóźnień.

---

Gdy weryfikacja jest zakończona, utwórz link pod swoją domeną niestandardową, przekazując domain_id w wywołaniu tworzenia linku - lub wybierz ją z selektora domeny w panelu lub aplikacji mobilnej. Link jest natychmiast dostępny pod adresem https://go.example.com/<slug> z ważnym certyfikatem.

Dalsza lektura: Niestandardowe krótkie linki z własną domeną: DNS, TLS i co działa na edge omawia pełną architekturę, w tym mechanikę cache edge, limity szybkości i tryby awarii w produkcji. Pełny przewodnik konfiguracji domeny, w tym zalecenia dotyczące CAA i dokumentacja API, jest dostępny pod adresem /docs/guides/custom-domains.

---

Marius Voß jest DevRel + edge infra w Elido. Jest właścicielem serwisów edge-redirect i domain-manager.

Powiązane artykuły na blogu#

• Osiąganie p95 < 15ms dla przekierowań z FRA, ASH i SGP
• Skonfiguruj markowe krótkie linki: wybierz domenę, wdróż w jedno popołudnie
• Głębokie linki dla aplikacji mobilnych bez SDK
• Rezydencja danych w UE dla narzędzi marketingowych: o co naprawdę pyta Twój DPO