Certyfikaty adresu IP od Let’s Encrypt: zastosowania i ryzyka SEO

Certyfikat adresu IP jest dla punktów końcowych infrastruktury - paneli administracyjnych, testów dostępności, połączeń z serwerem źródłowym. Nie dla publicznych stron. Jeśli goły adres serwuje Twoje strony po HTTPS, może trafić do Google jako zduplikowany host. A to pytanie przestało być teoretyczne 15 stycznia 2026 roku, kiedy Let’s Encrypt ogłosił, że certyfikaty krótkoterminowe i certyfikaty IP są ogólnie dostępne i ważne przez 160 godzin. Poniżej znajdziesz wskazówki, jak ocenić, czy taki certyfikat ma miejsce w Twojej konfiguracji.

Czym jest certyfikat adresu IP od Let’s Encrypt?

To certyfikat TLS, który uwierzytelnia połączenia z adresem IP zamiast z nazwą domeny. Let’s Encrypt wystawia go zarówno dla IPv4, jak i IPv6, i tylko jako jeden ze swoich certyfikatów krótkoterminowych. Dlaczego tak krótko? Bo adresy zmieniają właściciela znacznie łatwiej niż nazwy domen, więc kontrolę nad nimi trzeba potwierdzać częściej.

Pomysł jest stary. Standardy certyfikatów od zawsze dopuszczały identyfikatory IP, ale oferowało je tylko kilka urzędów certyfikacji, i to na małą skalę. Let’s Encrypt wstrzymywał się, dopóki nie wprowadził krótkich okresów ważności.

Jak zamówić certyfikat IP od Let’s Encrypt?

Wybierz profil shortlived w kliencie ACME, który obsługuje ACME Profiles, a potem przejdź walidację metodą http-01 albo tls-alpn-01. Krok po kroku:

1. Sprawdź, czy Twój klient obsługuje roboczą wersję specyfikacji ACME Profiles.
2. Skonfiguruj go tak, żeby zamawiał profil shortlived.
3. Jako wyzwanie wybierz http-01 albo tls-alpn-01 - metoda DNS nie potrafi potwierdzić kontroli nad adresem.
4. Zautomatyzuj odnawianie i ustaw alerty o niepowodzeniach.

Jeśli wyślesz zamówienie, którego szczegóły są sprzeczne z tymi zasadami, serwer ACME je odrzuci. Ponawianie nic nie da; klient wymaga aktualizacji albo zmiany konfiguracji.

I zapomnij o robieniu tego ręcznie. Przy tak krótkim okresie ważności wygasły certyfikat na administracyjnym punkcie końcowym odcina narzędzia, które od niego zależą.

Gdzie certyfikat SSL dla adresu IP ma sens

Na punktach końcowych, do których łączysz się po adresie, a nie po nazwie - tam, gdzie domeny nie ma albo gdzie po prostu nie chcesz zależeć od DNS:

• Panele administracyjne na stałym IP, które otwiera tylko Twój zespół.
• Testy dostępności i sondy monitoringu, które muszą działać także wtedy, gdy DNS nie odpowiada.
• Połączenia z serwerem źródłowym między proxy a stojącym za nim backendem.

Co zyskujesz w porównaniu z certyfikatem z podpisem własnym? Klienci weryfikują połączenie w zwykły sposób. Nie trzeba dodawać wyjątków zaufania ani pilnować prywatnego urzędu certyfikacji. Pamiętaj, że gdy przed istniejącym hostingiem stoi reverse proxy NGINX z adresami IP z UE lub USA, takie jak Jalvo, konfiguracja certyfikatu i tak zostaje na Twoim serwerze źródłowym.

Dlaczego publiczne strony powinny zostać przy nazwie domeny

Publiczna strona powinna nadal działać pod swoją domeną. To identyfikator, który znają odwiedzający i który sprawdzają przeglądarki.

Adres zmienia się przy każdej przeprowadzce hostingu. Domena nie - zabiera ze sobą linki, zakładki i historię wyszukiwania. Postawienie publicznej strony na krótkoterminowym certyfikacie IP dokłada więc presję odnawiania i nie daje odwiedzającym nic w zamian. Moim zdaniem to zły interes.

Ryzyko SEO: HTTPS na gołym IP jako zduplikowany host

Gdy goły adres IP odpowiada po HTTPS z ważnym certyfikatem i zwraca Twoje strony, masz drugi host z tą samą treścią. Zwykle przez przypadek. Domyślny blok server w NGINX obsługuje każde żądanie, którego nagłówek Host nie pasuje do niczego innego, w tym sam adres, a na wielu serwerach tym domyślnym blokiem jest główna strona.

Efektem jest równoległy zestaw adresów URL, który konkuruje z domeną kanoniczną i rozdziela sygnały między dwa hosty. To ta sama rodzina problemów co zduplikowane adresy URL przez ukośniki, tylko poziom wyżej, na nazwie hosta. Do tej pory ostrzeżenia przeglądarek o niepasującym certyfikacie ograniczały skalę problemu, bo mało kto linkował do takich adresów albo je udostępniał. Zaufany certyfikat usuwa tę przypadkową barierę.

Jak nie wpuścić hostów IP do Google

Przekieruj host IP na domenę kanoniczną kodem 301 albo całkiem go zablokuj. Które rozwiązanie wybrać? To zależy, do czego służy adres.

Na serwerze, który hostuje publiczną stronę, dodaj dla adresu osobny domyślny blok server, zwracający jedno przekierowanie 301 prosto na kanoniczny adres URL z https. Bez przeskoków - obowiązuje tu ta sama logika co przy spłaszczaniu łańcuchów przekierowań w NGINX. Panele administracyjne i testy dostępności to inna historia: zamykaj połączenie nieznanym klientom albo ogranicz dostęp listą dozwolonych adresów i uwierzytelnianiem, żeby nic tam nie dało się crawlować.

Adresy URL oparte na IP są już zaindeksowane? Wtedy przekierowanie jest czystszą poprawką, bo przenosi je na właściwy host. Jeśli wolisz blokować, dokładnie rozważ wybór między noindex a disallow, bo oba rozwiązania działają inaczej w przypadku stron, które są już znane. Na koniec wyślij żądanie na sam adres IP i upewnij się, że odpowiedzią jest przekierowanie albo odmowa. Nigdy strona główna.

W skrócie: używaj certyfikatu adresu IP na punktach końcowych infrastruktury, publiczną stronę trzymaj na jej domenie i dopilnuj, żeby adres nigdy nie serwował stron, które da się zaindeksować.

FAQ