Dlaczego certyfikat hostowany samodzielnie odnawia się lokalnie, ale nie działa z Internetu?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Certyfikat może odnowić się lokalnie, a mimo to nie odnowić się publicznie, gdy urząd certyfikacji ACME nie może dotrzeć do wyzwania przez ścieżkę dostępną z internetu ani go zweryfikować.

Na samodzielnie hostowanym serwerze NAS lub serwerze domowym lokalny test na sucho może potwierdzić, że Certbot, acme.sh lub odwrotne proxy potrafi utworzyć pliki wyzwania i uzyskać dostęp do własnej konfiguracji. Publiczne wystawienie certyfikatu wiąże się z innymi wymaganiami: autorytatywny DNS musi wskazywać prawidłowy adres, wybrana ścieżka IPv4 lub IPv6 musi być dostępna, router i zapora sieciowa muszą przekazać żądanie walidacyjne, a odwrotne proxy musi udostępnić dokładny token wyzwania, zanim przekierowania lub trasy aplikacji zakłócą ten proces.

Oddziel sukces lokalnego klienta od publicznej walidacji domeny

Przeczytaj dziennik odnowienia i ustal, co faktycznie zakończyło się powodzeniem. Sprawdzenie lokalnej konfiguracji, test analizy certyfikatu, zapis do webroota lub żądanie w środowisku testowym nie potwierdzają, że zewnętrzny urząd certyfikacji dotarł do serwera domowego.

Typowy przypadek dotyczący Nginx Proxy Manager wskazuje dostępności publicznego portu 80 jako pierwszy wymóg do sprawdzenia, gdy wyzwanie HTTP kończy się niepowodzeniem mimo działającego lokalnie interfejsu proxy.

Zapisz typ wyzwania, nazwę hosta, adres URL walidacji, rozpoznany adres oraz dokładny błąd urzędu certyfikacji. Kontynuuj diagnostykę od pierwszego zewnętrznego niepowodzenia — wyszukiwania DNS, połączenia TCP, kodu statusu HTTP, niezgodności tokenu lub walidacji dodatkowej — zamiast wielokrotnie wymuszać odnowienie bez nowych danych.

Porównaj autorytatywne rekordy A i AAAA z rzeczywistą ścieżką do serwera

Wykonaj zapytanie do autorytatywnego DNS dla każdej nazwy hosta certyfikatu i zapisz odpowiedzi A oraz AAAA. Porównaj je z bieżącym publicznym adresem IPv4 routera, dostępnym adresem IPv6 serwera oraz proxy, które faktycznie udostępnia wyzwanie.

W jednym z przypadków odnowienia w Virtualmin zakończyło się ono powodzeniem dopiero po usunięciu opublikowanego rekordu AAAA, który kierował walidację na uszkodzoną ścieżkę IPv6. Pokazuje to, jak uszkodzona ścieżka walidacji AAAA może przesłonić poza tym sprawną konfigurację IPv4.

Jeśli dana rodzina adresów nie jest w pełni dostępna, tymczasowo usuń ten rekord albo napraw zaporę, routing, nasłuchiwanie i ścieżkę proxy. Przed ponowną próbą wystawienia certyfikatu sprawdź również, czy wszystkie autorytatywne serwery nazw zwracają te same, aktualne rekordy.

Przetestuj dokładny adres URL wyzwania HTTP spoza domu

W przypadku HTTP-01 umieść nieszkodliwy plik testowy w skonfigurowanej ścieżce /.well-known/acme-challenge/ i zażądaj go z użyciem nazwy hosta certyfikatu przez HTTP, korzystając z danych komórkowych lub innej zewnętrznej sieci.

Raport dotyczący samodzielnego hostowania Home Assistant pokazuje, jak wyzwanie HTTP blokowane przez dostawcę internetu uniemożliwia walidację HTTP, nawet gdy sama usługa działa lokalnie.

Żądanie zewnętrzne musi dotrzeć do właściwego tokenu bez uwierzytelniania, strony captive portal, strony logowania routera, błędu 404 aplikacji ani przekierowania do niedostępnego miejsca docelowego. Jeśli port TCP 80 nigdy się nie otwiera, przed zmianą klienta ACME sprawdź dostawcę internetu, CGNAT, przekierowanie portu na routerze, zaporę hosta oraz nasłuchiwanie proxy.

Sprawdź, czy odwrotne proxy i webroot udostępniają ten sam token

Porównaj ścieżkę tokenu zapisaną przez klienta ACME z systemem plików lub tymczasowym mechanizmem odpowiedzi używanym przez publiczny host wirtualny. Kontenery, dowiązania montowania i oddzielne sieci proxy mogą sprawić, że klient zapisze plik w jednym katalogu, a NGINX lub Caddy będzie udostępniać inny.

Podczas jednego zewnętrznego żądania wyzwania sprawdź dziennik dostępu proxy. Żądanie, które dociera do serwera, ale zwraca 404, wskazuje na niezgodność trasy lub webroota; kod 401 lub 403 wskazuje na uwierzytelnianie albo filtrowanie; kod 502 wskazuje na zbędną zależność od usługi nadrzędnej w ścieżce wyzwania.

Nadaj lokalizacji wyzwania priorytet przed zwykłym routingiem aplikacji i zachowaj nazwę hosta. Utrzymuj proste przekierowania i weryfikuj je z zewnątrz; nie przekazuj tokenu do aplikacji backendowej, która może być niedostępna podczas odnowienia.

Sprawdź CGNAT, zapory i dostępność z wielu lokalizacji

Porównaj adres WAN routera z publicznym adresem IPv4 i potwierdź dostępność portu walidacyjnego z więcej niż jednej zewnętrznej sieci. Lokalny test z wykorzystaniem pętli zwrotnej NAT może zakończyć się powodzeniem, nawet gdy niezamawiany ruch z internetu nigdy nie dociera do routera.

Urzędy certyfikacji coraz częściej przeprowadzają walidację z wielu lokalizacji sieciowych, aby ograniczyć ataki na routing. Badania dotyczące wielu punktów obserwacyjnych walidacji wyjaśniają, dlaczego ścieżka dostępna z jednego kraju, u jednego dostawcy internetu lub przez jedną usługę testową może nadal nie przejść szerszej walidacji.

Na czas walidacji usuń geoblokowanie, filtry krajów, tymczasowe reguły blokowania oraz limity szybkości z wąskiej ścieżki wyzwania. Jeśli połączenie domowe znajduje się za CGNAT-em albo dostawca internetu blokuje wymagany port, użyj DNS-01 lub konstrukcji walidacyjnej opartej na połączeniu wychodzącym, zamiast osłabiać niezwiązane z tym reguły zapory.

Wybierz typ wyzwania odpowiedni dla granicy sieci

Pozostaw HTTP-01, gdy publiczny DNS jest poprawny, a port 80 może niezawodnie docierać do mechanizmu obsługującego wyzwanie. Użyj DNS-01, gdy dostęp przychodzący jest niedostępny, wymagane są certyfikaty wieloznaczne lub usługa musi pozostać prywatna.

Artykuł ZimaSpace o tym, jak CGNAT blokuje przychodzącą walidację, pomaga ustalić, kiedy zmiana metody ACME jest właściwsza niż naprawa lokalnego proxy.

Naprawa jest zakończona dopiero wtedy, gdy wymuszone odnowienie zakończy się powodzeniem za pośrednictwem produkcyjnego urzędu certyfikacji, nowy certyfikat zostanie wdrożony w aktywnym proxy, klienci zewnętrzni otrzymają nowy numer seryjny i datę wygaśnięcia, a test automatycznego odnowienia zadziała bez ręcznych zmian portów lub DNS.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.