# Certyfikaty TLS w Webship: Wbudowany ACME CA
Certyfikat TLS pełni dwie funkcje: pomaga w szyfrowaniu połączenia i informuje klienta, z jaką tożsamością się komunikuje. Szyfrowanie może być silne, podczas gdy decyzja o zaufaniu jest błędna dla odbiorców. Dlatego automatyzacja certyfikatów musi zaczynać się od jednego pytania: kto musi ufać tej stronie?
Webship 1.4.0 dokonuje tego wyboru niezależnie dla każdej skonfigurowanej strony. Publiczna strona internetowa może używać certyfikatu ACME zaufanego w przeglądarce, wewnętrzna usługa może używać wbudowanej prywatnej instytucji certyfikującej Webship, a strona z istniejącą PKI może zachować pliki certyfikatów zarządzane przez operatora. Wszystkie mogą korzystać z jednego procesu Webship bez współdzielenia jednego klucza prywatnego lub jednej granicy zaufania.
Cztery automatyczne tryby certyfikatu, wybierane dla każdej witryny
Pole certificate_mode należy do każdego wpisu [[sites]]. Nie jest to globalny przełącznik.
| Tryb | Zaufane źródło | Najlepsze dopasowanie | Ścieżka walidacji | | --- | --- | --- | --- | | per_site | Publiczne magazyny zaufania przeglądarek i systemów operacyjnych | Publiczna strona z jednym dokładnym hostname | Publiczne ACME z TLS-ALPN-01 | | flota | Publiczne magazyny zaufania przeglądarek i systemów operacyjnych | Duże zestawy nazw trzeciego i czwartego poziomu w ramach wyraźnie zarejestrowanych domen | Publiczne ACME z DNS-01 i stabilnymi fragmentami certyfikatów | | wbudowany | Prywatny root Webship zainstalowany przez operatora | Usługi wewnętrzne, zarządzane urządzenia, prywatne floty i środowiska testowe | Wydawanie w trakcie procesu; brak zewnętrznych wyzwań | | współdzielone | Publiczne magazyny zaufania przeglądarek i systemów operacyjnych | Starsze wdrożenia, które celowo używają jednej publicznej grupy multi-SAN | Publiczne ACME z TLS-ALPN-01 |
Domyślnie jest ustawione na per_site. Zamawia jeden publiczny certyfikat dla dokładnej nazwy witryny. Tryb fleet to skalowalna opcja publiczna dla wielu głębokich subdomen. Tryb osadzony korzysta z prywatnego CA Webship w procesie. Tryb współdzielony pozostaje dostępny dla zgodności, ale nie jest domyślny.
Kompletny certyfikat i klucz w ramach [sites.tls] zawsze mają pierwszeństwo przed automatycznym wydawaniem dla tej witryny.
Co oznacza „wbudowany ACME CA”
Sekcja konfiguracji nosi nazwę [acme_ca], ale wbudowany CA nie jest publiczną ani dostępną w sieci usługą ACME. Nie udostępnia żadnego punktu końcowego katalogu, nie przyjmuje zdalnej rejestracji, nie wywołuje API rejestratora i nie wykonuje żadnego wyzwania potwierdzającego kontrolę.
Zamiast tego, Webship utrzymuje całą prywatną ścieżkę emisji w jednym procesie:
- Strona wybiera certificate_mode = "embedded".
- Webship ładuje lub tworzy prywatną tożsamość główną w skonfigurowanym katalogu stanu.
- Webship generuje nowy klucz prywatny dla strony.
- Osadzony klucz root podpisuje certyfikat liściowy dla dokładnie tej nazwy.
- Webship weryfikuje ukończoną tożsamość przed jej zainstalowaniem w aktywnym rozwiązaniu TLS.
- Certyfikat jest następnie dostępny dla każdego włączonego protokołu dla tej witryny.
Wyzwanie sieciowe w stylu ACME udowodniłoby Webship tylko sobie, dlatego osadzona ścieżka celowo nie zawiera protokołu sieciowego. Sekcja [acme_ca] zawiera prywatny stan PKI: definiuje, gdzie znajduje się root i jak długo wydane certyfikaty końcowe pozostają ważne.
Skonfiguruj osadzony certyfikat dla jednej witryny
To jest minimalny kształt dla prywatnej strony:
~~~toml listen = "0.0.0.0:443"
[tls] unknown_sni = "odrzuć"
[automatyczny_tls] włączone = prawda cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[sites]] domena = "service.internal.example" root = "/srv/service" tryb_świadectwa = "osadzony"
[sites.protokoły] h1 = prawda h2 = prawda h3 = prawda ~~~
Tożsamość główna jest tworzona leniwie, gdy osadzona witryna potrzebuje jej po raz pierwszy. Webship przechowuje klucz główny z restrykcyjnymi uprawnieniami w state_dir. Certyfikat główny ma dziesięcioletni czas ważności; czas życia liścia jest kontrolowany przez leaf_validity_days.
Traktuj oba miejsca przechowywania jako stan produkcyjny:
- Pamięć podręczna ACME przechowuje automatycznie zarządzane tożsamości witryn.
- Katalog stanu wbudowanego CA zawiera prywatną tożsamość główną.
- Konto serwisowe potrzebuje dostępu, ale użytkownicy aplikacji nie.
- Kopie zapasowe muszą zachować poufność i uprawnienia do plików.
- Produkcja, rozwój i testowanie powinny korzystać z oddzielnych korzeni i oddzielnych katalogów.
Usunięcie katalogu głównego nie „resetuje TLS”. Tworzy nowy punkt zaufania. Klienci, którzy ufają staremu rootowi, odrzucą certyfikaty wydane przez zamiennik, dopóki ich magazyny zaufania nie zostaną zaktualizowane.
Prywatne powiernictwo jest zamierzone
Certyfikaty z wbudowanego urzędu certyfikacji nie są automatycznie uznawane za zaufane przez publiczne przeglądarki lub systemy operacyjne. Stają się zaufane dopiero po zainstalowaniu przez operatora eksportowanego certyfikatu root Webship w magazynie zaufania klienta.
To sprawia, że tryb osadzony jest dobrym wyborem dla:
- laptopy i telefony zarządzane przez firmę, zarejestrowane w systemie zarządzania urządzeniami;
- wewnętrzny ruch między usługami z wyraźnym pakietem CA;
- prywatne urządzenia i zarządzane floty brzegowe;
- środowiska rozwojowe i testowe, które muszą wykorzystywać rzeczywiste działanie TLS;
- niepołączone sieci, które nie mogą polegać na publicznym CA.
Nie jest to właściwy tryb dla zwykłej publicznej strony internetowej, której odwiedzający używają niezarządzanych przeglądarek. Użyj publicznej emisji per_site dla dokładnej publicznej nazwy, emisji fleet dla dużych zestawów publicznych subdomen, shared tylko dla celowego, starszego wdrożenia multi-SAN lub ręcznych plików z już zaufanego PKI.
Rozprowadzaj klientom wyłącznie certyfikat główny. Nigdy nie rozprowadzaj prywatnego klucza głównego. Posiadanie tego klucza daje jego właścicielowi uprawnienia do wydawania tożsamości zaufanych przez każdego zarejestrowanego klienta.
Certyfikaty publiczne i prywatne mogą współistnieć
Webship 1.4.0 może mieszać strategie certyfikatów na tym samym nasłuchiwaczu:
~~~toml listen = "0.0.0.0:443"
[tls] unknown_sni = "odrzuć"
[automatyczny_tls] włączone = prawda directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] zaakceptować_warunki_świadczenia_usług = prawda
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[sites]] domena = "www.example.com" root = "/srv/public" certificate_mode = "per_site"
[[sites]] domena = "control.internal.example" root = "/srv/control" tryb_świadectwa = "osadzony"
[[sites]] domena = "payments.example.com" root = "/srv/payments"
[sites.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~
Tutaj, www.example.com otrzymuje własny publiczny certyfikat ACME. control.internal.example otrzymuje prywatny certyfikat z wbudowanego CA. payments.example.com pozostaje pod zewnętrznym PKI operatora, ponieważ jego jawne pliki mają pierwszeństwo.
Publiczny katalog ACME jest ignorowany przez osadzone witryny. Osadzone źródło nigdy nie podpisuje publicznej witryny. Ręczna witryna nigdy nie jest cicho rejestrowana w żadnym z automatycznych procesów.
Jeden rozwiązywacz certyfikatów dla H1, H2, H3 i WebTransport
Wybór certyfikatu odbywa się podczas ustalania połączenia TLS, zanim zostanie wysłane żądanie HTTP. Webship używa nazwy serwera z ClientHello do wyboru tożsamości witryny, a następnie negocjuje protokół aplikacyjny.
- HTTP/1.1 i HTTP/2 używają TLS przez TCP.
- HTTP/3 i WebTransport używają TLS w QUIC przez UDP.
- Jedna ważna tożsamość witryny może obsługiwać każdy włączony protokół.
- HTTP/3 wymaga również dostępności UDP; H1 i H2 korzystają ze ścieżki TCP.
- Alt-Svc może reklamować H3 przy zachowaniu zapasowego połączenia TCP.
TCP, TLS i QUIC używają tego samego modelu tożsamości uwzględniającego witrynę. Dokładne nazwy mają pierwszeństwo, najdłuższy prawidłowy znak wieloznaczny wygrywa tam, gdzie skonfigurowano certyfikaty wieloznaczne, a nieznane nazwane SNI mogą być odrzucone zamiast otrzymywania niezwiązanego domyślnego certyfikatu.
Użyj unknown_sni = "reject" na multi-site listenerze, gdy nieznana nazwa hosta musi skutkować zamknięciem połączenia. Przetestuj rozpoznane nazwy, nieznane nazwy oraz oczekiwane zachowanie braku SNI przed wdrożeniem produkcyjnym.
Obracaj osadzone tożsamości bez przerwy w serwowaniu
Webship udostępnia stan certyfikatu i kontrolowane modyfikacje poprzez swój uwierzytelniony serwer MCP związany z loopback:
- webship.tls.get_status raportuje aktywnego rozwiązywacza certyfikatów i stan odnowienia.
- webship.tls.reissue_certificate natychmiast ponownie wydaje certyfikat dla automatycznie zarządzanej witryny tylko wtedy, gdy ta witryna używa trybu osadzonego.
- webship.tls.reload przeładowuje stan certyfikatu przez normalną chronioną ścieżkę TLS.
- webship.acme_ca.status raportuje, czy prywatny CA jest wybrany, jego katalog stanu, czas życia certyfikatu końcowego, liczbę wydanych certyfikatów, liczbę unieważnień oraz ostatnią próbkę domeny.
- webship.sites.apply dodaje lub usuwa witryny w stosunku do przypiętej wersji konfiguracji.
W przypadku wbudowanego ponownego wydania, Webship tworzy i weryfikuje zamiennik przed jego wprowadzeniem do użytku. Obecna ważna tożsamość działa nadal, aż nowa tożsamość będzie gotowa. Wycofana tożsamość jest rejestrowana dopiero po zainstalowaniu zamiennika.
Operacja natychmiastowego ponownego wydania celowo odrzuca publiczne certyfikaty per_site. Publiczne odnowienie musi pozostać w ramach publicznego cyklu życia ACME, zamiast być mylone z prywatnym podpisywaniem w toku. Członkostwo w trybie współdzielonym jest również zamrożone po ponownym uruchomieniu, ponieważ zmiana grupy multi-SAN przebudowuje granicę tożsamości.
MCP to uprzywilejowana powierzchnia sterująca. Trzymaj ją w pętli zwrotnej, wymagaj TLS i silnego tokenu dostępu, używaj uwierzytelnionego tunelu do zdalnej administracji i audytuj każdą zmianę.
Granice porażki, które mają znaczenie
Bezpieczny system certyfikatów musi zawieść w odpowiednim kierunku.
- Nowo skonfigurowana witryna osadzona nie otrzymuje tożsamości innej witryny podczas oczekiwania na wydanie.
- Nieprawidłowa zamiana nie jest instalowana na działającym certyfikacie.
- Jawne pliki ręczne uniemożliwiają automatyczne przypisanie właściciela tej witryny.
- Nieznany nazwany SNI może zostać odrzucony przed trasowaniem HTTP.
- Wbudowany urząd certyfikacji pozostaje prywatny i nie ma zdalnego punktu rejestracji.
- Tożsamości publiczne i osadzone używają osobnych ścieżek pamięci podręcznej w stanie automatycznego TLS.
Ostrzeżenie, że wbudowany CA nie jest zainicjalizowany, oznacza, że Webship nie mógł uzbroić skonfigurowanego katalogu stanu. Napraw własność, uprawnienia, trwałość lub dostępność magazynu przed wysłaniem ruchu do dotkniętej witryny. Nie obchodź tego błędu, kopiując klucz root innego środowiska.
Lista kontrolna produkcji
Przed włączeniem trybu osadzonego:
- Zidentyfikuj każdą grupę klientów, która musi ufać tej stronie.
- Utwórz kontrolowany proces eksportowania i instalowania certyfikatu głównego.
- Używaj oddzielnego stanu głównego dla produkcji, rozwoju i testowania.
- Utrzymuj i chroń katalog stanu wbudowanego CA oraz pamięć podręczną automatycznego TLS.
- Uruchom Webship na dedykowanym koncie serwisowym z dostępem tylko do niezbędnych materiałów kluczowych.
- Wybierz certificate_mode na każdej stronie, której granica zaufania musi być wyraźna.
- Ustaw i przetestuj politykę unknown-SNI.
- Włącz H1, H2 i H3 celowo i zweryfikuj zarówno ścieżki TCP, jak i UDP.
- Ćwicz ponowne wydanie, restart, kopię zapasową, przywracanie oraz weryfikację zaufania klienta poza środowiskiem produkcyjnym.
- Uruchom webship --check-config przed wdrożeniem, a następnie zweryfikuj wystawcę, nazwy, ważność, łańcuch i negocjowane protokoły z prawdziwego klienta.
Najpierw wybierz zaufanie, potem automatyzację
Wbudowany urząd certyfikacji (CA) eliminuje zależność od zewnętrznej usługi certyfikatów w przypadku prywatnej infrastruktury. Nie sprawia, że prywatny korzeń jest globalnie zaufany, i nie usuwa obowiązków operatora w zakresie PKI.
Webship automatyzuje generowanie kluczy, podpisywanie, walidację, instalację, rotację oraz wybór certyfikatów w całym protokole. Operator nadal posiada kontrolę nad kluczem głównym, rejestracją klientów, separacją środowisk, tworzeniem kopii zapasowych, przywracaniem danych oraz decyzją o użyciu publicznej lub prywatnej ścieżki zaufania.
Ta separacja jest cechą. Samodzielny serwer może automatycznie obsługiwać prywatny TLS bez udawania publicznego CA — a publiczne witryny nadal mogą używać zaufanego przez przeglądarki wydawania dla pojedynczych witryn lub całej floty w tym samym procesie.
Przeczytaj wersjonowaną dokumentację Webship 1.4.0 przed wdrożeniem. RFC 5280 definiuje profile certyfikatów i walidację, RFC 6066 definiuje sygnalizację nazwy serwera w TLS, RFC 8446 definiuje TLS 1.3, RFC 8555 definiuje publiczne ACME, a RFC 9525 definiuje weryfikację tożsamości usługi.