Rozwiązanie społecznościowe

Napraw ostrzeżenia HTTPS w ZimaOS i aplikacjach hostowanych samodzielnie

A ZimaOS user wanted to remove browser security warnings from the dashboard and every hosted app. The thread clarified the local ZimaOS certificate, Windows trust-store import, and why separate apps need their own HTTPS or a reverse proxy.

Jeśli przeglądarka ostrzega, że panel ZimaOS lub aplikacje są „Niezabezpieczone”, najpierw rozdziel główny panel ZimaOS od aplikacji działających za własnymi portami. Wątek źródłowy ostatecznie wykazał, że są to dwa różne problemy związane z HTTPS.

ZimaOS może wygenerować lokalny certyfikat dla https://zimaos.local. Zaufanie temu certyfikatowi może usunąć ostrzeżenie przeglądarki dotyczące panelu ZimaOS. Nie zapewnia ono automatycznie HTTPS dla Plex, Jellyfin, Emby, AdGuard ani innych aplikacji Docker, ponieważ są to oddzielne usługi HTTP. Aby udostępnić wiele aplikacji pod zaufanymi nazwami HTTPS, użyj odwrotnego serwera proxy, takiego jak Nginx Proxy Manager lub Caddy, wraz z odpowiednimi certyfikatami.

Pierwotne ostrzeżenie przeglądarki

Ostrzeżenie przeglądarki dotyczące certyfikatu wyświetlane przy otwieraniu lokalnego panelu ZimaOS przez HTTPS
Autor źródła chciał przestać przeklikiwać ostrzeżenie przeglądarki o certyfikacie przy otwieraniu ZimaOS.

Opcja 1: Wyłącz HTTPS dla lokalnego panelu ZimaOS

Zima-Giorgio odpowiedział, że HTTPS można wyłączyć w panelu Ustawienia ZimaOS. W zaufanej prywatnej sieci LAN zwykły HTTP może usunąć uciążliwe ostrzeżenia dotyczące certyfikatu, ale jednocześnie usuwa szyfrowanie transmisji między przeglądarką a panelem.

Ekran ustawień ZimaOS pokazujący lokalny certyfikat HTTPS i elementy sterujące zabezpieczeniami
W odpowiedzi źródłowej z 2025 roku wskazano, gdzie można zarządzać działaniem lokalnego HTTPS w ZimaOS.

W przypadku laptopów lub urządzeń przenoszonych między sieciami zaufanie certyfikatowi ZimaOS jest zazwyczaj lepszym rozwiązaniem niż globalne osłabianie zabezpieczeń przeglądarki.

Opcja 2: Pobierz lokalny certyfikat ZimaOS i zaufaj mu

W oficjalnej odpowiedzi zalecono pobranie wygenerowanego pliku CRT i zaufanie mu na urządzeniu klienckim. Po skonfigurowaniu zaufania użyj:

https://zimaos.local
Interfejs ZimaOS do pobierania wygenerowanego lokalnego certyfikatu HTTPS CRT
Wygenerowany plik CRT służy do ustanowienia zaufania dla lokalnej nazwy hosta panelu ZimaOS.

Zaufaj certyfikatowi CRT ZimaOS w systemie Windows

W źródłowej odpowiedzi przedstawiono tę procedurę dla systemu Windows:

  1. Naciśnij Win + R.
  2. Uruchom certmgr.msc.
  3. Otwórz Zaufane główne urzędy certyfikacji → Certyfikaty.
  4. Wybierz Wszystkie zadania → Importuj.
  5. Wybierz plik CRT pobrany z własnego systemu ZimaOS.
  6. Umieść go w Zaufane główne urzędy certyfikacji.
  7. Uruchom ponownie przeglądarkę.

Ufaj wyłącznie certyfikatowi uzyskanemu z własnej, znanej instancji ZimaOS. Zainstalowanie certyfikatu głównego oznacza zaufanie mu przy weryfikowaniu połączeń na tym kliencie.

Dlaczego certyfikat ZimaOS nie zabezpiecza Jellyfin, Plex ani Emby

Później autor oryginalnego wpisu pomyślnie zaimportował certyfikat w Pop!_OS i potwierdził, że zimaos.local działało, ale Plex, Emby i Jellyfin nadal były oznaczone jako niezabezpieczone.

Odpowiedź z 2026 roku wyjaśniła dlaczego: te aplikacje nasłuchują na osobnych usługach i portach. Przykłady obejmują:

Jellyfin: http://ZIMAOS_IP:8096
Plex:     http://ZIMAOS_IP:32400

Nie dziedziczą one automatycznie certyfikatu panelu ZimaOS. To oczekiwane zachowanie, a nie dowód na nieudane importowanie pliku CRT.

Użyj odwrotnego proxy HTTPS dla wielu aplikacji

Aby nadać aplikacjom nazwy takie jak:

https://jellyfin.example.com
https://emby.example.com
https://adguard.example.com

umieścić odwrotne proxy przed nimi. Proxy obsługuje certyfikaty TLS, a następnie przekazuje każde żądanie do wewnętrznego portu HTTP aplikacji.

Nginx Proxy Manager jest obecnie dostępny w sklepie aplikacji ZimaOS:

Nginx Proxy Manager dla ZimaOS

Dlaczego Nginx Proxy Manager zgłasza, że port 80 lub 443 jest już używany

Autor źródłowy próbował zainstalować proxy i natychmiast napotkał konflikt portów. Obecna dokumentacja Nginx Proxy Manager wymaga użycia tych standardowych portów:

80  → publiczny HTTP
443 → public HTTPS
81  → interfejs administracyjny NPM

Jeśli ZimaOS zajmuje już port 80 lub 443 hosta, NPM nie może jednocześnie przypisać tego samego portu hosta.

Oficjalna konfiguracja Nginx Proxy Manager

Port 81 nie jest publicznym miejscem docelowym HTTPS

Późniejszy użytkownik w tym samym wątku przekierował porty 80 i 443 routera na wewnętrzny port 81. Społeczność to skorygowała:

Router 80  → port NPM 80
Router 443 → port NPM 443

Port 81 jest interfejsem administracyjnym NPM. Nie powinien odbierać zwykłego publicznego ruchu witryny.

Wyzwanie HTTP a wyzwanie DNS

Wątek rozdzielił również dwie metody walidacji Let's Encrypt:

  • Wyzwanie HTTP: zwykle wymaga, aby urząd certyfikacji mógł połączyć się z proxy przez port 80.
  • Wyzwanie DNS: weryfikuje kontrolę nad domeną za pomocą rekordów lub API dostawcy DNS i może wyeliminować konieczność walidacji przez przychodzący port 80.

Wybierz świadomie jedną metodę. Nie łącz ustawień obu podejść bez zrozumienia, której ścieżki walidacji używa NPM.

Czy MySQL jest potrzebny tylko do uruchomienia Nginx Proxy Manager?

Nie. Obecna konfiguracja Nginx Proxy Manager obsługuje SQLite w prostej instalacji w pojedynczym kontenerze. Zewnętrzna baza danych MySQL/MariaDB/PostgreSQL jest opcjonalna.

To koryguje inną kwestię poruszoną w wątku źródłowym: początkujący użytkownik nie musi wdrażać MySQL tylko po to, aby rozpocząć konfigurację odwrotnego proxy dla kilku usług domowych.

Zmiana portu internetowego ZimaOS wiąże się z kompromisem

Później w wątku użytkownik przeniósł ZimaOS z portu 80 i mógł wtedy zainstalować Nginx Proxy Manager. Jednak odrębne raporty społeczności z 2026 roku wskazują, że zmiana portu pulpitu nawigacyjnego ZimaOS może zakłócić działanie klienta Zima na komputerach i urządzeniach mobilnych.

Zatem „przenieś ZimaOS z portu 80” nie jest uniwersalnym rozwiązaniem pozbawionym ryzyka. Zanim to zmienisz, zdecyduj, co jest ważniejsze w Twoim środowisku:

  • standardowym przekazaniem portów 80/443 przez odwrotny serwer proxy;
  • albo zachowaniem domyślnego działania klienta i mechanizmu wykrywania ZimaOS.

HTTPS tylko lokalnie a HTTPS publiczne

Jeśli używasz aplikacji wyłącznie w domu:

  • możesz pozostawić bezpośredni HTTP w zaufanej sieci LAN;
  • używaj certyfikatów zaufanych lokalnie;
  • albo uruchom wewnętrzny odwrotny serwer proxy i wewnętrzny DNS.

Jeśli chcesz korzystać z HTTPS dostępnego z internetu, użyj domeny, silnego uwierzytelniania, prawidłowo wystawionych certyfikatów oraz przemyślanego projektu zdalnego dostępu i bezpieczeństwa. Nie udostępniaj portów administracyjnych aplikacji ani interfejsu administracyjnego NPM tylko po to, aby w przeglądarce pojawiła się kłódka.

Lista kontrolna HTTPS w ZimaOS

  1. Zdecyduj, czy ostrzeżenie dotyczy zimaos.local lub oddzielną aplikację.
  2. W przypadku pulpitu nawigacyjnego ZimaOS pobierz wygenerowany certyfikat CRT i zaufaj mu, jeśli chcesz korzystać z lokalnego HTTPS bez ostrzeżeń.
  3. Użyj https://zimaos.local po zaufaniu certyfikatowi.
  4. Nie oczekuj, że certyfikat CRT ZimaOS zabezpieczy oddzielne porty aplikacji.
  5. Używaj odwrotnego serwera proxy dla nazw hostów HTTPS w wielu aplikacjach.
  6. Przed zainstalowaniem NPM sprawdź, która usługa korzysta z portów 80 i 443.
  7. Pozostaw port 81 NPM do celów administracyjnych, a nie do przekierowywania publicznej witryny.
  8. Wybierz walidację certyfikatu przez HTTP albo DNS, zależnie od swojej sieci.
  9. Nie udostępniaj niepotrzebnych usług administracyjnych w publicznym internecie.

Najczęściej zadawane pytania dotyczące HTTPS w ZimaOS

Dlaczego zimaos.local jest zabezpieczone, a Jellyfin nadal korzysta z HTTP?

Ponieważ certyfikat ZimaOS dotyczy nazwy hosta pulpitu nawigacyjnego. Jellyfin to oddzielna usługa nasłuchująca na własnym porcie.

Czy jeden odwrotny serwer proxy może zabezpieczyć wszystkie moje aplikacje ZimaOS?

Może terminować połączenia HTTPS dla wielu usług HTTP, pod warunkiem że każdy host proxy jest poprawnie skonfigurowany i proxy może połączyć się z docelową aplikacją.

Dlaczego Nginx Proxy Manager nie może uruchomić się na porcie 443?

Inna usługa jest już powiązana z tym portem hosta. W wątku źródłowym wystąpił ten problem, ponieważ ZimaOS i NPM konkurowały o standardowe porty internetowe.

Czy port 81 służy do przekierowywania publicznego ruchu HTTPS?

Nie. Port 81 to interfejs administracyjny NPM. Zwykły publiczny ruch powinien trafiać na porty 80 i 443.