Tworzenie certyfikatu wildcard Let's Encrypt

Certyfikat wildcard Let’s Encrypt jest przydatny, gdy kilka subdomen ma być chronionych jednym certyfikatem, na przykład app.example.com, vpn.example.com i portal.example.com. Takie rozwiązanie może być praktyczne w przypadku Sophos ZTNA, reverse proxy, środowisk testowych lub kilku wewnętrznych usług WWW.

Ważne jest właściwe założenie: certyfikaty Let’s Encrypt mają krótki okres ważności. Ich zaletą nie jest długa ważność, lecz bezpłatne wystawianie i możliwość automatyzacji. Jeśli certyfikat jest tworzony ręcznie za pomocą rekordu DNS TXT, późniejsze odnawianie trzeba świadomie zaplanować.

Jeżeli certyfikat ma być tworzony bezpośrednio na Sophos Firewall dla WAF, WebAdmin lub portali, zwykle lepszy jest mechanizm wbudowany w firewall: Konfiguracja certyfikatów Let’s Encrypt na Sophos Firewall. Ten artykuł opisuje zewnętrzną metodę wildcard z użyciem Certbot.

Kiedy certyfikat wildcard ma sens

Certyfikat wildcard obejmuje jeden poziom poniżej domeny. *.example.com obejmuje więc portal.example.com, ale nie obejmuje automatycznie example.com ani a.b.example.com.

• Wiele subdomen w tej samej strefie: Certyfikat wildcard może uprościć administrację.
• Tylko jedna usługa publiczna: Certyfikat dla jednego konkretnego FQDN jest często czytelniejszy.
• Certyfikat będzie używany na kilku systemach: Certyfikat wildcard może być praktyczny, ale dystrybucja klucza prywatnego musi być ściśle kontrolowana.
• Wymagane jest w pełni automatyczne odnawianie: Należy zaplanować dostawcę DNS z pluginem Certbot lub innego klienta ACME.
• Sophos Firewall ma chronić tylko WAF, WebAdmin lub portale: Warto sprawdzić wbudowany w firewall mechanizm Let’s Encrypt.

Certyfikat wildcard nie jest sam w sobie bezpieczniejszy. Jeżeli ten sam klucz prywatny znajduje się na kilku systemach, rośnie wpływ jego przejęcia. Trzeba więc udokumentować, na jakich systemach certyfikat został zaimportowany i kto odpowiada za klucz prywatny.

Wymagania

Do utworzenia certyfikatu wildcard potrzebne są:

• własna domena lub delegowana strefa subdomeny
• dostęp do rekordów DNS TXT domeny
• serwer Linux lub stacja administracyjna z Certbot
• uprawnienia do uruchomienia Certbot z prawami root
• plan odnawiania, importu i przechowywania klucza
• dostęp do systemu docelowego, na przykład Sophos Central ZTNA, reverse proxy lub firewalla

Certyfikaty wildcard są weryfikowane przez wyzwanie DNS-01. W tym celu tworzony jest rekord TXT pod adresem _acme-challenge.example.com. Let’s Encrypt sprawdza ten rekord DNS, a następnie wystawia certyfikat. Dokumentacja Let’s Encrypt dotycząca typów wyzwań opisuje podstawowe metody weryfikacji.

Instalacja Certbot

Strona projektu Certbot zaleca instalację przez Snap w wielu środowiskach Linux. Na odpowiednim systemie Linux podstawowa procedura wygląda następująco:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Jeżeli Certbot został już zainstalowany przez apt, dnf lub inny menedżer pakietów, najpierw trzeba sprawdzić, który plik wykonywalny jest rzeczywiście używany. Równoległe metody instalacji mogą w przeciwnym razie prowadzić do użycia nieoczekiwanej wersji lub innych zadań odnawiania niż zaplanowano.

Ręczne tworzenie certyfikatu wildcard

Do ręcznej weryfikacji DNS uruchamia się Certbot z opcjami --manual i --preferred-challenges dns. W tym przykładzie certyfikat ma obejmować zarówno example.com, jak i *.example.com:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Certbot wyświetla następnie jedną lub kilka wartości TXT. Gdy example.com i *.example.com są zamawiane jednocześnie, powstają dwa oddzielne wyzwania DNS-01. Obie wartości trzeba dodać jako osobne rekordy TXT pod _acme-challenge.example.com. Drugi rekord należy dodać bez nadpisywania pierwszego.

Przed kontynuowaniem w Certbot co najmniej autorytatywne serwery nazw domeny i zewnętrzny resolver powinny zwracać oczekiwane wartości TXT. Jeden resolver stanowi tylko wskazówkę, ponieważ dostawcy DNS mogą rozpropagowywać zmiany z różną szybkością zależnie od lokalizacji.

Praktyczna kontrola:

dig TXT _acme-challenge.example.com @1.1.1.1

Autorytatywne serwery nazw można znaleźć poleceniem dig NS example.com. Następnie ten sam rekord TXT można sprawdzić bezpośrednio na jednym z tych serwerów. Po pomyślnej weryfikacji należy usunąć niepotrzebne już wartości TXT wyzwania. Stare wartości utrudniają późniejsze kontrole, a przy dużej liczbie rekordów niepotrzebnie zwiększają odpowiedź DNS.

• certonly: Uzyskanie lub odnowienie certyfikatu bez jego instalowania.
• --manual: Ręczne ustawienie wartości DNS.
• --preferred-challenges dns: Użycie wyzwania DNS-01.
• -d example.com: Dodanie domeny głównej.
• -d '*.example.com': Dodanie domeny wildcard.

Domena główna i domena wildcard są odrębnymi nazwami. Jeżeli zamówiono tylko *.example.com, domena example.com nie zostanie dodana automatycznie. Przy jednoczesnym zamawianiu obu nazw może być potrzebnych kilka rekordów TXT o tej samej nazwie. DNS to obsługuje, a weryfikacja często kończy się niepowodzeniem właśnie dlatego, że istniejąca wartość TXT została przypadkowo nadpisana.

Lokalizowanie plików certyfikatu

Certbot pokazuje rzeczywistą nazwę certyfikatu, objęte domeny, datę wygaśnięcia i ścieżki plików za pomocą tego polecenia tylko do odczytu:

sudo certbot certificates

Po pomyślnym wystawieniu pliki znajdują się zwykle w katalogu:

/etc/letsencrypt/live/example.com/

Ważne pliki:

• fullchain.pem: Certyfikat wraz z certyfikatami pośrednimi.
• cert.pem: Tylko certyfikat serwera.
• privkey.pem: Klucz prywatny.
• chain.pem: Certyfikaty pośrednie.

Wiele systemów docelowych wymaga plików fullchain.pem i privkey.pem. Niektóre formularze importu oczekują osobno certyfikatu i klucza, a inne wymagają również łańcucha. Przed importem trzeba ustalić, jakiego formatu oczekuje system docelowy.

⚠️ privkey.pem jest kluczem prywatnym. Ten plik nie może trafić do zgłoszeń, czatów, poczty elektronicznej ani niezabezpieczonych repozytoriów. Każdy, kto uzyska klucz prywatny, może nadużyć certyfikatu.

Planowanie odnowienia

Ręczna metoda z --manual jest prosta podczas testów i jednorazowych operacji, ale tylko częściowo nadaje się do certyfikatów produkcyjnych. Bez automatyzacji przy każdym odnowieniu trzeba ustawić nową wartość DNS TXT.

W środowisku produkcyjnym dostępne są trzy rozsądne opcje:

• Plugin DNS dla dostawcy: Odpowiedni, gdy Certbot może aktualizować rekordy DNS przez API.
• Inny klient ACME z automatyzacją DNS: Odpowiedni, gdy dostawca lub platforma ma lepszą obsługę w innym kliencie.
• Ręczne odnowienie z wyznaczonym właścicielem i przypomnieniem: Odpowiednie tylko do testów lub rzadko używanych certyfikatów.

Dane dostępowe do API DNS są szczególnie wrażliwe. Token DNS powinien być ograniczony do wymaganej strefy i, jeśli to możliwe, do potrzebnych typów rekordów. Poświadczenia z szerokimi prawami administratora domeny nie powinny być przechowywane bez zabezpieczenia na serwerze WWW.

Odnowienie testuje się zwykle poleceniem:

sudo certbot renew --dry-run

W przypadku certyfikatów utworzonych przez ręczną weryfikację DNS ten test ma znaczenie tylko wtedy, gdy proces DNS jest zautomatyzowany lub ręczne hooki działają prawidłowo.

Pomyślne odnowienie na systemie Certbot nie aktualizuje automatycznie certyfikatu wcześniej zaimportowanego do Sophos Firewall, ZTNA lub reverse proxy. Potrzebny jest udokumentowany ponowny import albo przetestowany proces wdrożenia uruchamiany dopiero po pomyślnym odnowieniu. Po każdym wdrożeniu należy sprawdzić nazwy, łańcuch i nową datę wygaśnięcia bezpośrednio na systemie docelowym.

Import do środowisk Sophos

Przed importem certyfikatu do Sophos ZTNA, firewalla, reverse proxy lub innego systemu związanego z Sophos trzeba sprawdzić:

• Czy nazwa certyfikatu odpowiada publicznej nazwie hosta?
• Czy oprócz wildcard potrzebna jest również domena główna?
• Czy system docelowy oczekuje fullchain.pem, czy osobnych składników certyfikatu?
• Czy akceptuje klucz prywatny, czy trzeba go przekonwertować do innego formatu?
• Czy istnieje udokumentowana procedura kolejnego odnowienia?
• Czy wiadomo, na jakich systemach zaimportowano ten sam certyfikat?

Jeżeli certyfikat jest potrzebny tylko dla WAF, WebAdmin lub portali na Sophos Firewall, wbudowany proces jest często prostszy, ponieważ wystawianie i odnawianie odbywa się bezpośrednio na firewallu. W przypadku prawdziwych certyfikatów wildcard nadal istotna jest zewnętrzna metoda Certbot lub ACME. Artykuł Importowanie i przypisywanie certyfikatów na Sophos Firewall wyjaśnia następnie, jak sprawdzić klucz prywatny, łańcuch CA i przypisanie do usługi.

Typowe błędy

• Weryfikacja kończy się niepowodzeniem: Rekord TXT nie jest jeszcze widoczny, nazwa strefy DNS jest nieprawidłowa albo nadpisano jedną z kilku wartości TXT. Sprawdzić poleceniem dig TXT _acme-challenge.example.com @1.1.1.1.
• Certyfikat nie obejmuje example.com: Zamówiono tylko *.example.com. Dodać domenę główną opcją -d example.com.
• Certyfikat nie obejmuje a.b.example.com: Wildcard obejmuje tylko jeden poziom subdomeny. Zaplanować osobny certyfikat lub odpowiedni wildcard dla głębszej strefy.
• Odnowienie nie uruchamia się automatycznie: Ręczna metoda DNS nie jest zautomatyzowana. Sprawdzić odpowiedni plugin DNS lub innego klienta ACME.
• Certbot odnowił certyfikat, ale system docelowy nadal prezentuje stary: Nie wykonano ponownego importu lub procesu wdrożenia. Sprawdzić numer seryjny lub datę wygaśnięcia bezpośrednio na systemie docelowym.
• Import kończy się niepowodzeniem: Plik lub format jest nieprawidłowy. Porównać wymagania dotyczące fullchain.pem, cert.pem, privkey.pem i łańcucha certyfikatów.
• Kopie klucza tworzą ryzyko bezpieczeństwa: Klucz prywatny znajduje się na kilku systemach. Udokumentować miejsca przechowywania, uprawnienia dostępu i punkty importu.

Lista kontrolna

• Zdefiniowana domena i wymagany poziom subdomeny.
• Świadomie wybrane domena główna i wildcard.
• Dostęp do DNS i uprawnienie do tworzenia rekordów TXT.
• Certbot zainstalowany w spójny sposób.
• Wyzwanie DNS-01 pomyślnie zweryfikowane.
• Pliki certyfikatu i klucz prywatny bezpiecznie przechowywane.
• Znany system docelowy i wymagany format importu.
• Odnowienie zaplanowane z właścicielem, przypomnieniem lub automatyzacją DNS.
• Przetestowany ponowny import lub proces wdrożenia do systemu docelowego.
• Stare certyfikaty i klucze usunięte w kontrolowany sposób po udanej migracji.

Często zadawane pytania