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 und Container-Image-Downloads — über die Domain via TLS, und der insecure-registries-Workaround wird nicht mehr benötigt.

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.