HTTPS i certyfikaty

Gdy aplikacja na podłączonym urządzeniu udostępnia interfejs webowy, Appliance udostępnia go przez swój wbudowany tunel. Wybierasz, jak przeglądarki docierają do Appliance — są trzy tryby, od zerowej konfiguracji po w pełni podpisany firmowo. Wybierz jeden i wykonaj jego kroki.

To nie to samo, co Za firmowym proxy. Tamta strona dotyczy zaufania Appliance do twojego firmowego CA dla ruchu wychodzącego (Appliance → chmura, przez proxy przechwytujące TLS). Ta strona dotyczy odwrotnego kierunku — ruchu przychodzącego od przeglądarek w twojej sieci docierających do Appliance. Te dwie kwestie są niezależne.

Tryb 1 — Zwykły HTTP (domyślny)

Co otrzymujesz. Wszystko przez zwykły HTTP pod adresem Appliance:

Każdy interfejs aplikacji jest publikowany na własnym, automatycznie przypisanym porcie; interfejs IronFlock pokazuje dokładny link do każdego z nich. Interfejsy aplikacji pozostają za loginem Appliance — otwarcie jednego przekierowuje do logowania, chyba że jesteś zalogowany i autoryzowany dla danego urządzenia (port można oznaczyć jako publiczny dla poszczególnych aplikacji tam, gdzie chcesz go udostępnić).

Co musisz zrobić. Nic. To jest domyślne — po prostu użyj adresu IP lub nazwy hosta Appliance w swojej sieci lokalnej. Bez DNS, bez certyfikatu, bez udziału firmowego IT.

Kiedy używać. Appliance w zaufanej, segmentowanej sieci — szafa sterownicza w VLAN maszyny/OT — gdzie zwykły HTTP jest normą, a dostęp jest kontrolowany przez segmentację sieci i zabezpieczenia fizyczne.

Tryb 2 — HTTPS z samodzielnie wystawionym CA

Co otrzymujesz. Appliance włącza swój wbudowany ingress HTTPS i serwuje wszystko przez HTTPS pod twoją domeną — używając certyfikatu, który sam generuje. Nie ma reverse proxy do uruchomienia ani adresów URL do przepięcia; instalator konfiguruje wszystko za ciebie.

Co musisz zrobić.

1. Wybierz domenę, która rozwiązuje się na Appliance dla każdej przeglądarki i urządzenia, które będą jej używać, i ustaw na nią zarówno APPLIANCE_HOST, jak i APPLIANCE_DOMAIN. Ponieważ Appliance sam wystawia certyfikat, dowolna nazwa działa — jedynym wymogiem jest, aby się rozwiązywała. Do czegokolwiek poza szybkim testem użyj wewnętrznej domeny, którą kontrolujesz (np. appliance.corp.example.com) z rekordem wildcard we własnym DNS: odizolowana lub ograniczona w DNS sieć Appliance zwykle nie może dotrzeć do publicznej usługi nip.io, na której opiera się domyślna nazwa <host-ip>.nip.io. (Ta domyślna nazwa działa tam, gdzie sieć ma dostęp do internetu — dlatego działa na maszynie deweloperskiej.)

2. Dodaj wildcard DNS dla domeny, oba rekordy wskazujące na adres IP hosta Appliance:

   • *.<APPLIANCE_DOMAIN> — obejmuje interfejsy aplikacji oraz każdą poddomenę usługi.
   • <APPLIANCE_DOMAIN> (apex) — główny interfejs po nazwie.

   (Usługa wildcard DNS taka jak nip.io już rozwiązuje je automatycznie, więc nie ma rekordów do dodania — ale zależy to od osiągalności tej zewnętrznej usługi.)

3. Zainstaluj z --tls:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive --tls

   --interactive pyta o APPLIANCE_HOST / APPLIANCE_DOMAIN (lub ustaw IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN dla instalacji bezobsługowej). Appliance generuje lokalny CA w /opt/ironflock/certs/ca/rootCA.crt oraz certyfikat wildcard podpisany przez niego.

4. Rozdystrybuuj główny CA do maszyn klienckich. Wypchnij rootCA.crt przez swój MDM lub dodaj go do magazynu zaufania systemu operacyjnego/przeglądarki każdej maszyny. Dopóki maszyna mu nie ufa, jej przeglądarka ostrzega.

5. Odnów w ciągu roku. Certyfikat serwera jest ograniczony do ~1 roku — przeglądarki odrzucają dłużej ważne. Aby odnowić, usuń tls.crt/tls.key w katalogu certyfikatów i uruchom ponownie instalator; podpisze on świeży certyfikat przy użyciu tego samego CA, więc zaufanie, które rozdystrybuowałeś, nadal działa.

Urządzenia pozostają na ścieżce zwykłego IP. Tylko strona przeglądarki przechodzi na HTTPS. Podłączone urządzenia nadal docierają do Appliance przez jego IP, więc nie musisz instalować CA na każdym urządzeniu.

Kiedy używać. Chcesz HTTPS we współdzielonej sieci, ale nie masz (lub nie chcesz czekać na) certyfikatu od firmowego IT i możesz wypchnąć główny CA do maszyn, które będą otwierać interfejs.

Tryb 3 — HTTPS z twoim firmowym certyfikatem

Co otrzymujesz. Ten sam pełny HTTPS Appliance co w Trybie 2 — ale certyfikat pochodzi z CA twojej organizacji, którego główny certyfikat jest już zaufany na każdej zarządzanej maszynie. Bez ostrzeżeń przeglądarki, nic do dystrybucji. Urządzenia również przechodzą na domenę.

Co musisz zrobić.

1. Wybierz wewnętrzną domenę, którą kontrolujesz i ustaw APPLIANCE_HOST oraz APPLIANCE_DOMAIN na nią (np. appliance.corp.example.com). Tutaj musi to być twoja własna domena — CA wystawia certyfikaty tylko dla domen, które posiadasz, więc nazwa nip.io nie zadziała w tym trybie.
2. Dodaj wildcard DNS — *.<APPLIANCE_DOMAIN> oraz apex, wskazujące na adres IP hosta Appliance — jak w Trybie 2, krok 2.
3. Uzyskaj certyfikat wildcard dla *.<APPLIANCE_DOMAIN> z wewnętrznego CA, jako dwa pliki PEM: tls.crt (najlepiej pełny łańcuch) oraz niezaszyfrowany tls.key.
4. Zainstaluj ze swoim certyfikatem:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive \
         --tls-cert /path/to/wildcard.crt \
         --tls-key  /path/to/wildcard.key

   --tls-cert implikuje --tls. Równoważne zmienne środowiskowe: IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. Rotuj według harmonogramu swojego CA. Umieść nowe pliki PEM w katalogu certyfikatów i zrestartuj:

   sudo cp wildcard.crt /opt/ironflock/certs/tls.crt
   sudo cp wildcard.key /opt/ironflock/certs/tls.key
   sudo chmod 0600 /opt/ironflock/certs/tls.key
   sudo systemctl restart ironflock.service

   Appliance przeładowuje certyfikat automatycznie, gdy plik się zmieni; restart po prostu stosuje go natychmiast. Ponowne uruchomienie instalatora nigdy nie nadpisuje istniejącego certyfikatu, chyba że przekażesz --tls-cert.

Urządzenia również przechodzą na domenę. Ponieważ certyfikat jest zaufany w całej flocie, ruch urządzeń — łącze urządzenia, pobieranie obrazów kontenerów i aktualizacje agenta urządzeń — także przebiega przez domenę z TLS, a obejście insecure-registries nie jest już potrzebne. Dotyczy to obrazów aplikacji zbudowanych po przełączeniu; aplikacje zainstalowane wcześniej zachowują adres rejestru, względem którego zostały zbudowane, a agent 0.21.3 i nowszy rozwiązuje go samodzielnie — zobacz wymaganie 4 poniżej.

Czego wymagają podłączone urządzenia w tym trybie

Każde urządzenie brzegowe łączące się z appliance musi:

1. Rozwiązywać domenę. <APPLIANCE_DOMAIN> i jej subdomeny (rekord wildcard) muszą rozwiązywać się na adres IP appliance z sieci urządzenia — te same rekordy DNS, które obsługują przeglądarki.
2. Dosięgać appliance na porcie 443 — jedynym porcie, jakiego urządzenia potrzebują do połączenia z platformą, do aktualizacji agenta urządzeń (serwowanych z https://registry.<APPLIANCE_DOMAIN>/dl — port 15002 nie jest w tym trybie potrzebny) oraz do obrazów aplikacji zbudowanych po przełączeniu (aplikacji zainstalowanych wcześniej dotyczy wymaganie 4). To właśnie czyni tryb 3 właściwym wyborem dla urządzeń w mocno ograniczonych sieciach: wychodzący 443 jest dozwolony praktycznie wszędzie, a połączenie działa również przez firmowe proxy HTTP (przekaż agentowi proxy tak, jak opisano w Za firmowym proxy → Urządzenia brzegowe). W trybie prostym urządzenia potrzebują natomiast bezpośredniego dostępu do kilku portów usług appliance, które firmowe zapory i proxy często blokują — zobacz Łączność urządzeń.
3. Ufać firmowemu głównemu urzędowi certyfikacji. Agent i Docker weryfikują certyfikat appliance względem magazynu zaufania systemu operacyjnego urządzenia:
   • Maszyny zarządzane (Windows dołączony do domeny, Linux zarządzany przez MDM) zwykle już ufają Twojemu firmowemu certyfikatowi głównemu — nie ma nic do zrobienia.
   • Niezarządzany Windows: zainstaluj główny certyfikat CA w magazynie komputera z wiersza poleceń o podwyższonych uprawnieniach — certutil -addstore -f Root corporate-root-ca.crt — a następnie zrestartuj Docker Desktop (przy starcie importuje zaufane certyfikaty główne z magazynu Windows) oraz usługę agenta (Restart-Service reagent).
   • Linux: sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates, a potem zrestartuj Dockera (sudo systemctl restart docker) i agenta.
   • Kontenery aplikacji dziedziczą to zaufanie automatycznie (agent 0.21.3 i nowsze). Kontener zawiera wyłącznie pakiet CA ze swojego obrazu bazowego, a żaden obraz bazowy nie zawiera wewnętrznego certyfikatu głównego — aplikacja łącząca się z urządzeniem appliance po TLS nie mogła więc zweryfikować jego certyfikatu. Agent montuje teraz magazyn zaufania samego urządzenia w każdym kontenerze aplikacji, tylko do odczytu, pod ścieżką /etc/ironflock/certs/ca-bundle.crt, i kieruje do niego typowe środowiska uruchomieniowe (SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS). Nie trzeba nic konfigurować, ale samo urządzenie musi ufać certyfikatowi głównemu, bo to właśnie to zaufanie przekazuje agent. Jeśli aplikacja ustawia własną zmienną SSL_CERT_FILE, zostaje ona zachowana.
4. Zaktualizować agenta urządzeń do 0.21.3 lub nowszego — albo ponownie opublikować aplikacje zainstalowane przed przełączeniem. Zapisany plik compose aplikacji zawiera w pełni kwalifikowane odwołania do obrazów — <APPLIANCE_IP>:15001/apps/… — wpisane na stałe w momencie budowania aplikacji. Te odwołania są danymi: przeniesienie appliance na domenę nie przepisuje żadnego pliku compose. Agent 0.21.3 i nowszy rozwiązuje takie odwołanie na rejestr, dla którego skonfigurowane jest samo urządzenie, więc aplikacja zainstalowana przed przełączeniem działa dalej przez domenę bez żadnych działań — pierwszy start po aktualizacji pobiera każdy obraz raz pod nową nazwą. Starszy agent używa odwołania tak, jak je zapisano, i nadal łączy się ze starym IP i portem: jego urządzenie wciąż potrzebuje portu rejestru (15001) dostępnego w sieci lokalnej, a sam port 443 mu nie wystarcza, dopóki aplikacja nie zostanie przebudowana i ponownie opublikowana względem registry.<APPLIANCE_DOMAIN>. Swoją własną stronę appliance obsługuje automatycznie: dopóki jego własny agent jest starszy niż 0.21.3 i istnieje takie odwołanie, utrzymuje rejestr dostępny w sieci LAN i wypisuje objęte tym pliki compose w wyniku działania instalatora. Gdy agent jest aktualny — albo te aplikacje zostaną ponownie opublikowane — następne sudo ironflock-update nie znajduje już nic, na co miałoby czekać, i samo wycofuje rejestr z sieci LAN.

Kiedy używać. Standardowa firmowa ścieżka on-prem: twoja organizacja już prowadzi wewnętrzny CA, więc certyfikat wildcard jest wystawiany raz i zaufany wszędzie bez konfiguracji na każdej maszynie.

Rozwiązywanie problemów

Link do interfejsu aplikacji się nie otwiera / połączenie odrzucone. W trybie zwykłym interfejsy aplikacji są pod http://<host>:<port> — upewnij się, że używasz dokładnego linku pokazanego w interfejsie IronFlock (port jest przypisywany dla każdej aplikacji) i że nic w sieci nie blokuje tego portu.

Przeglądarka ostrzega, że certyfikat nie jest zaufany (po --tls). Klient jeszcze nie ufa CA certyfikatu. W Trybie 2 wdróż CA wygenerowany przez Appliance (/opt/ironflock/certs/ca/rootCA.crt) na kliencie. W Trybie 3 upewnij się, że klient ufa głównemu certyfikatowi twojego wewnętrznego CA.

Certyfikat wygasł (samodzielnie wystawiony). Samodzielnie wystawiony certyfikat serwera jest ważny przez około rok (przeglądarki odrzucają dłużej ważne). Odnów go: usuń tls.crt/tls.key w katalogu certyfikatów i uruchom ponownie instalator, aby podpisać ponownie tym samym, wciąż zaufanym CA — albo przełącz się na --tls-cert z własnego CA.

Niezgodność nazwy certyfikatu. Certyfikat nie jest wildcardem dla używanej domeny. Musi obejmować *.<APPLIANCE_DOMAIN>, a domena w adresie URL musi pasować do APPLIANCE_DOMAIN.

Poddomena się nie rozwiązuje (po --tls). Brakuje wildcard DNS. Dodaj rekord A *.<APPLIANCE_DOMAIN> wskazujący na host Appliance — obejmuje on interfejsy aplikacji i każdą poddomenę usługi.

Aplikacja nie startuje lub nie pobiera obrazu po przejściu na tryb 3 — “connection refused” na porcie 15001. Plik compose aplikacji nadal odwołuje się do rejestru przez adres IP appliance, bo właśnie względem niego został zbudowany, a agent urządzenia jest starszy niż 0.21.3 — od tej wersji agent sam rozwiązuje takie odwołanie na własny rejestr. Zaktualizuj agenta urządzeń albo przebuduj i ponownie opublikuj aplikację, tak aby jej obraz rozwiązywał się przez registry.<APPLIANCE_DOMAIN>. Do tego czasu rejestr musi pozostać dostępny w sieci lokalnej, o co appliance dba samo — zwykłe sudo ironflock-update przywraca powiązanie z siecią LAN i wypisuje pliki compose, które nadal zawierają stare odwołanie.

Aplikacja działa, ale nigdy się nie łączy, a w jej logu co kilka sekund powtarza się ta sama próba połączenia. Kontener aplikacji nie może zweryfikować certyfikatu urządzenia appliance: uzgadnianie TLS jest przerywane tuż po certyfikacie serwera, a SDK ponawia próby w nieskończoność — podczas gdy samo urządzenie pozostaje online, bo agent korzysta z magazynu zaufania systemu operacyjnego, a kontener nie. Zaktualizuj agenta urządzenia do wersji 0.21.3 lub nowszej, która przekazuje magazyn zaufania urządzenia do kontenerów aplikacji, i upewnij się, że urządzenie ufa firmowemu certyfikatowi głównemu (wymaganie 3 powyżej). Polecenie docker logs <kontener> na urządzeniu pokaże błąd weryfikacji certyfikatu. Przy starszym agencie rozwiązanie jest osobne dla każdej aplikacji: dodaj certyfikat główny do obrazu albo zamontuj go i ustaw SSL_CERT_FILE w pliku compose aplikacji.

Urządzenie nie łączy się po przejściu na tryb 3. Przejdź przez cztery powyższe wymagania urządzeń: domena musi rozwiązywać się z sieci urządzenia, port 443 na appliance musi być osiągalny (bezpośrednio albo przez proxy urządzenia), urządzenie musi ufać firmowemu certyfikatowi głównemu, a aplikacje zainstalowane przed przełączeniem potrzebują agenta 0.21.3 albo ponownej publikacji, żeby przestały potrzebować portu rejestru. W systemie Windows log agenta w C:\ProgramData\IronFlock\Reagent\reagent.log (w Linuksie /var/log/reagent.log) pokazuje dokładny błąd połączenia — błąd DNS, przekroczenie czasu albo błąd weryfikacji certyfikatu wskazują każdy na jedno z pierwszych trzech wymagań.