HTTPS & Zertifikate

Wenn eine App auf einem verbundenen Gerät eine Weboberfläche bereitstellt, macht die Appliance sie über ihren integrierten Tunnel erreichbar. Sie entscheiden, wie Browser die Appliance erreichen — es gibt drei Modi, von null Setup bis vollständig unternehmenssigniert. Wählen Sie einen aus und folgen Sie seinen Schritten.

Nicht dasselbe wie Hinter einem Unternehmens-Proxy. Jene Seite behandelt, dass die Appliance Ihrer Unternehmens-CA für ausgehenden Verkehr vertraut (Appliance → Cloud, durch einen TLS-abfangenden Proxy). Diese Seite betrifft die entgegengesetzte Richtung — eingehenden Verkehr von Browsern in Ihrem Netzwerk, die die Appliance erreichen. Beide sind voneinander unabhängig.

Modus 1 — Einfaches HTTP (Standard)

Was Sie erhalten. Alles über einfaches HTTP unter der Adresse der Appliance:

Jede App-UI wird auf ihrem eigenen, automatisch zugewiesenen Port veröffentlicht; die IronFlock-UI zeigt für jede den genauen Link an. App-UIs bleiben hinter dem Appliance-Login — beim Öffnen einer UI wird auf den Login umgeleitet, sofern Sie nicht angemeldet und für dieses Gerät berechtigt sind (ein Port kann pro App als öffentlich markiert werden, wo Sie ihn offen haben möchten).

Was Sie tun müssen. Nichts. Dies ist der Standard — verwenden Sie einfach die IP oder den Hostnamen der Appliance in Ihrem lokalen Netzwerk. Kein DNS, kein Zertifikat, keine Beteiligung der Unternehmens-IT.

Wann Sie ihn verwenden. Eine Appliance in einem vertrauenswürdigen, segmentierten Netzwerk — ein Schaltschrank in einem Maschinen-/OT-VLAN — in dem einfaches HTTP die Norm ist und der Zugriff durch Netzwerksegmentierung und physische Sicherheit gesteuert wird.

Modus 2 — HTTPS mit einer selbst ausgestellten CA

Was Sie erhalten. Die Appliance aktiviert ihren integrierten HTTPS-Ingress und stellt alles über HTTPS unter Ihrer Domain bereit — mit einem Zertifikat, das sie selbst generiert. Es gibt keinen Reverse-Proxy zu betreiben und keine URLs neu zu verdrahten; der Installer richtet alles ein.

Was Sie tun müssen.

1. Wählen Sie eine Domain, die für jeden Browser und jedes Gerät, das sie nutzt, auf die Appliance auflöst, und setzen Sie sowohl APPLIANCE_HOST als auch APPLIANCE_DOMAIN darauf. Da die Appliance das Zertifikat selbst ausstellt, funktioniert jeder Name — die einzige Voraussetzung ist, dass er auflöst. Für alles über einen schnellen Test hinaus verwenden Sie eine interne Domain, die Sie kontrollieren (z. B. appliance.corp.example.com) mit einem Wildcard-Eintrag in Ihrem eigenen DNS: Ein isoliertes oder DNS-beschränktes Appliance-Netzwerk kann den öffentlichen nip.io-Dienst, auf den sich der Standardname <host-ip>.nip.io stützt, in der Regel nicht erreichen. (Dieser Standard funktioniert dort, wo das Netzwerk das Internet erreichen kann — weshalb er auf einer Entwicklermaschine funktioniert.)

2. Fügen Sie Wildcard-DNS für die Domain hinzu, beide Einträge zeigen auf die Host-IP der Appliance:

   • *.<APPLIANCE_DOMAIN> — deckt die App-UIs und jede Dienst-Subdomain ab.
   • <APPLIANCE_DOMAIN> (Apex) — die Haupt-UI über den Namen.

   (Ein Wildcard-DNS-Dienst wie nip.io löst diese bereits automatisch auf, sodass keine Einträge hinzuzufügen sind — dies hängt jedoch davon ab, dass dieser externe Dienst erreichbar ist.)

3. Installieren Sie mit --tls:

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

   --interactive fragt nach APPLIANCE_HOST / APPLIANCE_DOMAIN (oder setzen Sie IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN für eine unbeaufsichtigte Installation). Die Appliance generiert eine lokale CA unter /opt/ironflock/certs/ca/rootCA.crt und ein davon signiertes Wildcard-Zertifikat.

4. Verteilen Sie die CA-Root an Client-Maschinen. Rollen Sie rootCA.crt über Ihr MDM aus oder fügen Sie es dem OS-/Browser-Vertrauensspeicher jeder Maschine hinzu. Bis eine Maschine ihr vertraut, warnt deren Browser.

5. Erneuern Sie innerhalb eines Jahres. Das Server-Zertifikat ist auf etwa 1 Jahr begrenzt — Browser lehnen länger gültige ab. Zum Erneuern löschen Sie tls.crt/tls.key im Zertifikatsverzeichnis und führen den Installer erneut aus; er signiert ein frisches Zertifikat gegen dieselbe CA, sodass das von Ihnen verteilte Vertrauen weiterhin funktioniert.

Geräte bleiben auf dem Pfad über die reine IP. Nur die Browser-Seite wechselt zu HTTPS. Verbundene Geräte erreichen die Appliance weiterhin über ihre IP, sodass Sie die CA nicht auf jedem Gerät installieren müssen.

Wann Sie ihn verwenden. Sie möchten HTTPS in einem gemeinsam genutzten Netzwerk, haben aber kein Zertifikat der Unternehmens-IT (oder möchten nicht darauf warten), und Sie können eine Root-CA an die Maschinen ausrollen, die die UI öffnen werden.

Modus 3 — HTTPS mit Ihrem Unternehmenszertifikat

Was Sie erhalten. Dasselbe vollständige Appliance-HTTPS wie in Modus 2 — aber das Zertifikat stammt von der CA Ihrer Organisation, deren Root bereits auf jeder verwalteten Maschine vertrauenswürdig ist. Keine Browser-Warnungen, nichts zu verteilen. Auch Geräte wechseln auf die Domain.

Was Sie tun müssen.

1. Wählen Sie eine interne Domain, die Sie kontrollieren und setzen Sie APPLIANCE_HOST und APPLIANCE_DOMAIN darauf (z. B. appliance.corp.example.com). Hier muss es Ihre eigene Domain sein — eine CA stellt nur Zertifikate für Domains aus, die Ihnen gehören, sodass ein nip.io-Name in diesem Modus nicht funktioniert.
2. Fügen Sie Wildcard-DNS hinzu — *.<APPLIANCE_DOMAIN> und den Apex, zeigend auf die Host-IP der Appliance — wie in Modus 2, Schritt 2.
3. Beschaffen Sie ein Wildcard-Zertifikat für *.<APPLIANCE_DOMAIN> von Ihrer internen CA, als zwei PEM-Dateien: tls.crt (idealerweise Full-Chain) und ein unverschlüsselter tls.key.
4. Installieren Sie mit Ihrem Zertifikat:

   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 impliziert --tls. Entsprechende Umgebungsvariablen: IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. Rotieren Sie nach dem Zeitplan Ihrer CA. Legen Sie die neuen PEM-Dateien in das Zertifikatsverzeichnis und starten Sie neu:

   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

   Die Appliance lädt das Zertifikat automatisch neu, wenn sich die Datei ändert; der Neustart wendet es lediglich sofort an. Ein erneutes Ausführen des Installers überschreibt niemals ein vorhandenes Zertifikat, es sei denn, Sie übergeben --tls-cert.

Auch Geräte wechseln auf die Domain. Da das Zertifikat flottenweit vertrauenswürdig ist, läuft auch der Geräteverkehr — die Geräteverbindung, Container-Image-Downloads und Updates des Geräte-Agenten — über die Domain via TLS, und der insecure-registries-Workaround wird nicht mehr benötigt. Das gilt für App-Images, die nach der Umstellung gebaut wurden; vorher installierte Apps behalten die Registry-Adresse, gegen die sie gebaut wurden, die Agent 0.21.3 und neuer selbst auflösen — siehe Anforderung 4 unten.

Was verbundene Geräte in diesem Modus brauchen

Jedes Edge-Gerät, das sich mit der Appliance verbindet, muss:

1. Die Domain auflösen. <APPLIANCE_DOMAIN> und ihre Subdomains (der Wildcard-Eintrag) müssen aus dem Netzwerk des Geräts auf die Appliance-IP auflösen — dieselben DNS-Einträge, die auch Browser bedienen.
2. Die Appliance über Port 443 erreichen — der einzige Port, den Geräte für die Plattformverbindung, für Updates des Geräte-Agenten (bereitgestellt unter https://registry.<APPLIANCE_DOMAIN>/dl — Port 15002 wird in diesem Modus nicht benötigt) und für nach der Umstellung gebaute App-Images brauchen (vorher installierte Apps brauchen Anforderung 4). Genau das macht Modus 3 zur richtigen Wahl für Geräte in abgeschotteten Netzwerken: Ausgehendes 443 ist nahezu überall erlaubt, und die Verbindung funktioniert außerdem über einen Unternehmens-HTTP-Proxy (geben Sie dem Agenten den Proxy wie unter Hinter einem Unternehmens-Proxy → Edge-Geräte beschrieben). Im einfachen Modus benötigen Geräte dagegen direkten Zugriff auf mehrere Appliance-Dienstports, die Unternehmens-Firewalls und -Proxys häufig blockieren — siehe Gerätekonnektivität.
3. Ihrer Unternehmens-Root-CA vertrauen. Der Agent und Docker prüfen das Zertifikat der Appliance gegen den Vertrauensspeicher des Betriebssystems auf dem Gerät:
   • Verwaltete Maschinen (domänenbeigetretenes Windows, MDM-verwaltetes Linux) vertrauen Ihrer Unternehmens-Root meist schon — nichts zu tun.
   • Unverwaltetes Windows: Installieren Sie die Root-CA in den Maschinenspeicher aus einer Eingabeaufforderung mit Administratorrechten — certutil -addstore -f Root corporate-root-ca.crt — und starten Sie dann Docker Desktop (es importiert beim Start die vertrauenswürdigen Roots aus dem Windows-Speicher) und den Agenten-Dienst neu (Restart-Service reagent).
   • Linux: sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates, danach Docker (sudo systemctl restart docker) und den Agenten neu starten.
   • App-Container übernehmen dieses Vertrauen automatisch (Agent 0.21.3 und neuer). Ein Container enthält nur das CA-Bundle seines Basis-Images, und kein Basis-Image enthält eine interne Stamm-CA — eine App, die sich über TLS mit der Appliance verbindet, konnte deren Zertifikat also nicht prüfen. Der Agent bindet den Vertrauensspeicher des Geräts jetzt schreibgeschützt unter /etc/ironflock/certs/ca-bundle.crt in jeden App-Container ein und verweist die üblichen Laufzeitumgebungen darauf (SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS). Es ist nichts zu konfigurieren — das Gerät selbst muss der Stamm-CA aber vertrauen, denn genau dieses Vertrauen gibt der Agent weiter. Setzt eine App ihr eigenes SSL_CERT_FILE, bleibt dieses erhalten.
4. Den Geräte-Agenten auf 0.21.3 oder neuer aktualisieren — oder vor der Umstellung installierte Apps neu veröffentlichen. Die gespeicherte Compose-Datei einer App enthält voll qualifizierte Image-Referenzen — <APPLIANCE_IP>:15001/apps/… — die beim Bauen der App fest eingetragen wurden. Diese Referenzen sind Daten: Der Wechsel der Appliance auf eine Domain schreibt keine Compose-Datei um. Agent 0.21.3 und neuer lösen eine solche Referenz auf die Registry auf, für die das Gerät selbst konfiguriert ist — eine vor der Umstellung installierte App läuft damit ohne Zutun über die Domain weiter, und der erste Start nach dem Update zieht jedes Image einmal unter dem neuen Namen. Ein älterer Agent verwendet die Referenz wie eingetragen und wählt weiterhin die alte IP und den alten Port: Sein Gerät braucht den Registry-Port (15001) weiterhin im lokalen Netzwerk erreichbar — Port 443 allein genügt dafür nicht — bis die App neu gebaut und gegen registry.<APPLIANCE_DOMAIN> neu veröffentlicht ist. Ihre eigene Seite regelt die Appliance automatisch: Solange ihr eigener Agent älter als 0.21.3 ist und eine solche Referenz existiert, hält sie die Registry im LAN erreichbar und listet die betroffenen Compose-Dateien in der Installer-Ausgabe auf. Ist der Agent aktuell — oder sind diese Apps neu veröffentlicht — findet das nächste sudo ironflock-update nichts mehr, worauf es warten müsste, und nimmt die Registry von selbst aus dem LAN.

Wann Sie ihn verwenden. Der Standard-Pfad für Unternehmen mit On-Premises: Ihre Organisation betreibt bereits eine interne CA, sodass ein Wildcard-Zertifikat einmal ausgestellt und überall ohne Setup pro Maschine vertraut wird.

Fehlerbehebung

Ein App-UI-Link öffnet sich nicht / Verbindung abgelehnt. Im einfachen Modus liegen App-UIs unter http://<host>:<port> — stellen Sie sicher, dass Sie den genau in der IronFlock-UI angezeigten Link verwenden (der Port wird pro App zugewiesen) und dass nichts im Netzwerk diesen Port blockiert.

Der Browser warnt, dass dem Zertifikat nicht vertraut wird (nach --tls). Der Client vertraut der CA des Zertifikats noch nicht. In Modus 2 rollen Sie die von der Appliance generierte CA (/opt/ironflock/certs/ca/rootCA.crt) auf den Client aus. In Modus 3 stellen Sie sicher, dass der Client Ihrer internen CA-Root vertraut.

Zertifikat abgelaufen (selbst ausgestellt). Ein selbst ausgestelltes Server-Zertifikat ist etwa ein Jahr gültig (Browser lehnen länger gültige ab). Erneuern Sie es: Löschen Sie tls.crt/tls.key im Zertifikatsverzeichnis und führen Sie den Installer erneut aus, um gegen dieselbe, weiterhin vertrauenswürdige CA neu zu signieren — oder wechseln Sie zu einem --tls-cert Ihrer eigenen CA.

Zertifikatsnamen-Konflikt. Das Zertifikat ist kein Wildcard für die verwendete Domain. Es muss *.<APPLIANCE_DOMAIN> abdecken, und die Domain der URL muss mit APPLIANCE_DOMAIN übereinstimmen.

Eine Subdomain löst nicht auf (nach --tls). Wildcard-DNS fehlt. Fügen Sie einen *.<APPLIANCE_DOMAIN>-A-Eintrag hinzu, der auf den Appliance-Host zeigt — er deckt die App-UIs und jede Dienst-Subdomain ab.

Eine App startet nach dem Wechsel zu Modus 3 nicht oder kann ihr Image nicht ziehen — “connection refused” auf Port 15001. Die Compose-Datei der App referenziert die Registry noch über die IP-Adresse der Appliance, weil sie dagegen gebaut wurde, und der Agent des Geräts ist älter als 0.21.3 — ab dieser Version löst der Agent eine solche Referenz selbst auf seine eigene Registry auf. Aktualisieren Sie den Geräte-Agenten, oder bauen und veröffentlichen Sie die App neu, damit ihr Image über registry.<APPLIANCE_DOMAIN> aufgelöst wird. Bis dahin muss die Registry im lokalen Netzwerk erreichbar bleiben, was die Appliance selbst regelt — ein einfaches sudo ironflock-update stellt die LAN-Bindung wieder her und nennt die Compose-Dateien, die noch eine alte Referenz enthalten.

Eine App läuft, verbindet sich aber nie, und ihr Log wiederholt alle paar Sekunden denselben Verbindungsversuch. Der Container der App kann das Zertifikat der Appliance nicht prüfen: Der TLS-Handshake wird direkt nach dem Serverzertifikat abgebrochen und das SDK versucht es endlos erneut — während das Gerät selbst online bleibt, weil der Agent den Vertrauensspeicher des Betriebssystems nutzt und der Container nicht. Aktualisieren Sie den Geräte-Agenten auf 0.21.3 oder neuer, der den Vertrauensspeicher des Geräts an App-Container weitergibt, und stellen Sie sicher, dass das Gerät Ihrer Unternehmens-Stamm-CA vertraut (Anforderung 3 oben). docker logs <container> auf dem Gerät zeigt den Zertifikatsfehler. Bei einem älteren Agenten hilft nur eine Lösung pro App: die Stamm-CA ins Image aufnehmen oder einbinden und SSL_CERT_FILE in der Compose-Datei der App setzen.

Ein Gerät verbindet sich nach dem Wechsel zu Modus 3 nicht. Arbeiten Sie die vier Geräteanforderungen von oben durch: Die Domain muss aus dem Gerätenetzwerk auflösen, Port 443 auf der Appliance muss erreichbar sein (direkt oder über den Proxy des Geräts), das Gerät muss Ihrer Unternehmens-Root-CA vertrauen, und vor der Umstellung installierte Apps brauchen Agent 0.21.3 oder eine Neuveröffentlichung, bevor sie den Registry-Port nicht mehr brauchen. Unter Windows zeigt das Agenten-Log unter C:\ProgramData\IronFlock\Reagent\reagent.log (unter Linux /var/log/reagent.log) den genauen Verbindungsfehler — ein DNS-Fehler, ein Timeout oder ein Zertifikatsprüfungsfehler weisen jeweils auf eine der ersten drei Anforderungen hin.