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 i pobieranie obrazów kontenerów — także przebiega przez domenę z TLS, a obejście insecure-registries nie jest już potrzebne.

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.