HTTPS と証明書

接続されたデバイス上のアプリが Web インターフェースを公開すると、アプライアンスは組み込みのトンネルを通じてそれに到達できるようにします。ブラウザがどのようにアプライアンスへ到達するかを選択できます — ゼロ設定から完全な企業署名まで、3 つのモードがあります。1 つを選び、その手順に従ってください。

企業プロキシの背後で とは別物です。 そのページは、アプライアンスがアウトバウンドトラフィックのために貴社の企業 CA を信頼する（アプライアンス → クラウド、TLS 傍受型プロキシ経由）ことを扱っています。このページはその逆方向 — 貴社ネットワーク上のブラウザからアプライアンスに到達するインバウンドトラフィックです。両者は互いに独立しています。

モード 1 — プレーン HTTP（デフォルト）

得られるもの。 すべてがアプライアンスのアドレス上でプレーン HTTP により提供されます。

各アプリ UI は、自動的に割り当てられた独自のポート上で公開されます。IronFlock UI が各 UI の正確なリンクを表示します。アプリ UI はアプライアンスのログインの背後にとどまります — サインインしてそのデバイスに対して認可されていない限り、UI を開くとログインにリダイレクトされます（開放したい場合は、アプリごとにポートを公開としてマークできます）。

必要な作業。 ありません。これがデフォルトです — ローカルネットワーク上でアプライアンスの IP またはホスト名を使うだけです。DNS も証明書も、企業 IT の関与も不要です。

使いどころ。 信頼済みでセグメント化されたネットワーク上のアプライアンス — マシン/OT VLAN 上の制御盤など — で、プレーン HTTP が通常であり、アクセスがネットワークセグメント化と物理的セキュリティによって制御されている場合。

モード 2 — 自己発行 CA による HTTPS

得られるもの。 アプライアンスは組み込みの HTTPS イングレスを有効化し、自ら生成した証明書を使って、すべてを貴社ドメイン配下の HTTPS で提供します。稼働させるリバースプロキシも、配線し直す URL もありません。インストーラがすべて設定します。

必要な作業。

1. アプライアンスに解決するドメインを選び、それを使用するすべてのブラウザとデバイスに対して解決できるようにして、APPLIANCE_HOST と APPLIANCE_DOMAIN の両方をそれに設定します。アプライアンス自身が証明書を発行するため、任意の名前が使えます — 唯一の要件は、それが解決することです。簡単なテスト以上の用途では、自社の DNS 内にワイルドカードレコードを持つ、自分が管理する内部ドメイン（例：appliance.corp.example.com）を使用してください。隔離された、または DNS が制限されたアプライアンスネットワークは通常、デフォルトの <host-ip>.nip.io 名が依存する公開の nip.io サービスに到達できません。（そのデフォルトは、ネットワークがインターネットに到達できる環境では動作します — だからこそ開発マシンでは動作するのです。）

2. ワイルドカード DNS を追加します。両方のレコードをアプライアンスホストの IP に向けます。

   • *.<APPLIANCE_DOMAIN> — アプリ UI およびすべてのサービスサブドメインをカバーします。
   • <APPLIANCE_DOMAIN>（apex） — 名前によるメイン UI。

   （nip.io のようなワイルドカード DNS サービスは、これらを自動的に解決するため、追加するレコードはありません — ただし、その外部サービスに到達できることが前提です。）

3. --tls を付けてインストール：

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

   --interactive は APPLIANCE_HOST / APPLIANCE_DOMAIN の入力を求めます（無人インストールの場合は IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN を設定）。アプライアンスは /opt/ironflock/certs/ca/rootCA.crt にローカル CA を生成し、それによって署名されたワイルドカード証明書を生成します。

4. CA ルートをクライアントマシンに配布します。 rootCA.crt を MDM で配布するか、各マシンの OS/ブラウザの信頼ストアに追加します。マシンがそれを信頼するまで、そのブラウザは警告を表示します。

5. 1 年以内に更新します。 サーバー証明書は約 1 年に制限されます — ブラウザはそれより長寿命のものを拒否します。更新するには、証明書ディレクトリ内の tls.crt/tls.key を削除してインストーラを再実行します。同じ CA に対して新しい証明書を再署名するため、配布済みの信頼はそのまま機能し続けます。

デバイスはプレーン IP のパスにとどまります。 HTTPS に移行するのはブラウザ側だけです。接続されたデバイスは引き続きアプライアンスに IP 経由で到達するため、すべてのデバイスに CA をインストールする必要はありません。

使いどころ。 共有ネットワークで HTTPS を使いたいが、企業 IT からの証明書がない（あるいは待ちたくない）場合で、UI を開くマシンにルート CA を配布できる場合。

モード 3 — 企業証明書による HTTPS

得られるもの。 モード 2 と同じ、アプライアンス全体の HTTPS ですが、証明書は貴社組織の CA から発行され、そのルートはすべての管理対象マシンですでに信頼されています。ブラウザの警告はなく、配布するものもありません。デバイスもドメインへ移行します。

必要な作業。

1. 自分が管理する内部ドメインを選び、APPLIANCE_HOST と APPLIANCE_DOMAIN をそれに設定します（例：appliance.corp.example.com）。ここでは、必ず自社ドメインでなければなりません — CA は所有するドメインに対してのみ証明書を発行するため、このモードでは nip.io 名は使えません。
2. ワイルドカード DNS を追加 — モード 2 のステップ 2 と同様に、*.<APPLIANCE_DOMAIN> と apex をアプライアンスホストの IP に向けます。
3. 社内 CA から *.<APPLIANCE_DOMAIN> のワイルドカード証明書を取得します。2 つの PEM ファイルとして：tls.crt（理想的にはフルチェーン）と、暗号化されていない tls.key です。
4. 証明書を付けてインストール：

   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 は --tls を含意します。同等の環境変数：IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY。
5. 貴社 CA のスケジュールに従ってローテーションします。 新しい PEM ファイルを証明書ディレクトリに置いて再起動します。

   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

   ファイルが変更されると、アプライアンスは自動的に証明書を再読み込みします。再起動は、それを即座に適用するだけです。インストーラの再実行は、--tls-cert を渡さない限り、既存の証明書を上書きすることはありません。

デバイスもドメインへ移行します。 証明書がフリート全体で信頼されるため、デバイストラフィック — デバイスリンク、コンテナイメージのプル、デバイスエージェントの更新 — も TLS 経由でドメインを通して動作し、insecure-registries の回避策はもはや不要になります。 これは切り替え後にビルドされたアプリイメージに当てはまります。切り替え前にインストールされたアプリは、ビルド時のレジストリアドレスをそのまま保持しますが、エージェント 0.21.3 以降はこれを自動的に解決します。下の要件 4 を参照してください。

このモードで接続デバイスに必要なもの

アプライアンスに接続する各エッジデバイスには次が必要です:

1. ドメインを解決できること。 <APPLIANCE_DOMAIN> とそのサブドメイン（ワイルドカードレコード）が、デバイスのネットワークからアプライアンスの IP に解決される必要があります — ブラウザーに使われるものと同じ DNS レコードです。
2. ポート 443 でアプライアンスに到達できること — プラットフォーム接続、デバイスエージェントの更新（https://registry.<APPLIANCE_DOMAIN>/dl から配信され、このモードではポート 15002 は不要です）、そして切り替え後にビルドされたアプリイメージのために、デバイスが必要とする唯一のポートです（切り替え前にインストールされたアプリについては要件 4 を参照）。これがモード 3 を、閉じられたネットワークにあるデバイスにとって最適な選択にしています。外向きの 443 はほぼどこでも許可されており、接続は企業 HTTP プロキシ経由でも機能します（企業プロキシの背後で → エッジデバイス の説明のとおりエージェントにプロキシを渡してください）。一方、シンプルモードではデバイスがアプライアンスの複数のサービスポートへ直接アクセスする必要があり、企業のファイアウォールやプロキシはそれらを頻繁にブロックします — デバイス接続 を参照してください。
3. 企業ルート CA を信頼していること。 エージェントと Docker は、デバイスのオペレーティングシステムの信頼ストアに対してアプライアンスの証明書を検証します:
   • 管理対象マシン（ドメイン参加済みの Windows、MDM 管理下の Linux）は通常すでに企業ルートを信頼しています — 対応は不要です。
   • 管理外の Windows: 管理者権限のプロンプトからルート CA をマシンストアにインストールし — certutil -addstore -f Root corporate-root-ca.crt — その後 Docker Desktop（起動時に Windows ストアから信頼されたルートを取り込みます）とエージェントサービス（Restart-Service reagent）を再起動します。
   • Linux: sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates を実行し、その後 Docker（sudo systemctl restart docker）とエージェントを再起動します。
   • アプリコンテナはこの信頼を自動的に引き継ぎます（エージェント 0.21.3 以降）。コンテナはベースイメージに同梱された CA バンドルしか持たず、社内ルート CA を含むベースイメージは存在しません。そのため TLS でアプライアンスに接続するアプリは、証明書を検証できませんでした。エージェントは現在、デバイス自身のトラストストアを各アプリコンテナへ読み取り専用で /etc/ironflock/certs/ca-bundle.crt にマウントし、主要なランタイムをそこへ向けます（SSL_CERT_FILE、REQUESTS_CA_BUNDLE、NODE_EXTRA_CA_CERTS）。設定は不要ですが、エージェントが引き渡すのはデバイスの信頼そのものなので、デバイス側がルート CA を信頼している必要があります。アプリが独自の SSL_CERT_FILE を設定している場合は、その値が維持されます。
4. デバイスエージェントを 0.21.3 以降へ更新すること — または切り替え前にインストールされたアプリを再公開すること。 アプリの保存済み compose ファイルには、アプリのビルド時に埋め込まれた完全修飾のイメージ参照 — <APPLIANCE_IP>:15001/apps/… — が含まれます。これらの参照はデータです。アプライアンスをドメインへ移しても compose ファイルは書き換えられません。エージェント 0.21.3 以降は、そうした参照をデバイス自身に設定されたレジストリへ解決するため、切り替え前にインストールされたアプリも何もせずにドメイン経由で動き続けます。更新後の最初の起動で、各イメージが新しい名前で一度だけ取得されます。それより古いエージェントは参照を書かれたまま使い、古い IP とポートへ接続し続けます。そのデバイスは、アプリを再ビルドして registry.<APPLIANCE_DOMAIN> に対して再公開するまで、レジストリポート（15001）がローカルネットワークで到達可能である必要があり、ポート 443 だけでは足りません。 アプライアンス自身の側は自動的に処理されます。自身のエージェントが 0.21.3 より古く、そうした参照が 1 つでも残っている間はレジストリを LAN から到達可能に保ち、該当する compose ファイルをインストーラーの出力に列挙します。エージェントを更新すると — またはそれらのアプリを再公開すると — 次の sudo ironflock-update は待つべきものを見つけず、自動でレジストリを LAN から外します。

使いどころ。 標準的な企業オンプレミスのパスです。貴社組織はすでに社内 CA を運用しているため、ワイルドカード証明書は一度発行されれば、マシンごとの設定なしにどこでも信頼されます。

トラブルシューティング

アプリ UI のリンクが開かない / 接続が拒否される。 プレーンモードでは、アプリ UI は http://<host>:<port> にあります — IronFlock UI に表示される正確なリンクを使っていること（ポートはアプリごとに割り当てられます）、およびネットワーク上の何かがそのポートをブロックしていないことを確認してください。

ブラウザが証明書は信頼されていないと警告する（--tls 後）。 クライアントが証明書の CA をまだ信頼していません。モード 2 では、アプライアンスが生成した CA（/opt/ironflock/certs/ca/rootCA.crt）をクライアントに配布してください。モード 3 では、クライアントが貴社の社内 CA ルートを信頼していることを確認してください。

証明書の有効期限が切れた（自己発行）。 自己発行のサーバー証明書は約 1 年間有効です（ブラウザはそれより長寿命のものを拒否します）。更新してください：証明書ディレクトリ内の tls.crt/tls.key を削除し、インストーラを再実行して、同じ、いまだ信頼されている CA に対して再署名します — または、自社 CA からの --tls-cert に切り替えてください。

証明書の名前が一致しない。 証明書が使用中のドメインのワイルドカードになっていません。*.<APPLIANCE_DOMAIN> をカバーし、URL のドメインが APPLIANCE_DOMAIN と一致していなければなりません。

サブドメインが解決しない（--tls 後）。 ワイルドカード DNS が不足しています。アプライアンスホストを指す *.<APPLIANCE_DOMAIN> の A レコードを追加してください — これがアプリ UI とすべてのサービスサブドメインをカバーします。

モード 3 に切り替えた後、アプリが起動しない、またはイメージを取得できない — ポート 15001 で “connection refused”。 そのアプリの compose ファイルは、ビルド時の対象だったアプライアンスの IP アドレスでレジストリを参照したままで、そのデバイスのエージェントは 0.21.3 より古いバージョンです。このバージョン以降、エージェントはそうした参照を自身のレジストリへ自動的に解決します。デバイスエージェントを更新するか、イメージが registry.<APPLIANCE_DOMAIN> 経由で解決されるよう、アプリを再ビルドして再公開してください。それまではレジストリがローカルネットワークで到達可能なままである必要があり、これはアプライアンスが自分で手配します — 通常の sudo ironflock-update が LAN バインドを復元し、古い参照を残している compose ファイルを列挙します。

アプリは起動しているのに接続できず、ログに数秒ごとに同じ接続試行が繰り返される。 アプリのコンテナがアプライアンスの証明書を検証できていません。TLS ハンドシェイクはサーバー証明書の直後で中断され、SDK は無限に再試行します。エージェントは OS のトラストストアを使い、コンテナは使わないため、デバイス自体はオンラインのままです。デバイスのトラストストアをアプリコンテナへ引き渡す 0.21.3 以降にエージェントを更新し、デバイスが社内ルート CA を信頼していること（上記の要件 3）を確認してください。デバイス上で docker logs <コンテナ> を実行すると証明書の検証エラーが確認できます。古いエージェントではアプリごとの対処が必要です。ルート CA をイメージに追加するか、マウントしてアプリの compose ファイルで SSL_CERT_FILE を設定してください。

モード 3 に切り替えた後、デバイスが接続できない。 上記の 4 つのデバイス要件を順に確認してください。ドメインがデバイスのネットワークから解決されること、アプライアンスのポート 443 に到達できること（直接またはデバイスのプロキシ経由）、デバイスが企業ルート CA を信頼していること、そして切り替え前にインストールされたアプリがレジストリポートを必要としなくなるには、エージェント 0.21.3 か再公開が必要であること。Windows では C:\ProgramData\IronFlock\Reagent\reagent.log（Linux では /var/log/reagent.log）のエージェントログに正確な接続エラーが出ます — DNS の失敗、タイムアウト、証明書検証エラーは、それぞれ最初の 3 つの要件のいずれかを指しています。