HTTPS と証明書
接続されたデバイス上のアプリが Web インターフェースを公開すると、アプライアンスは組み込みのトンネルを通じてそれに到達できるようにします。ブラウザがどのようにアプライアンスへ到達するかを選択できます — ゼロ設定から完全な企業署名まで、3 つのモードがあります。1 つを選び、その手順に従ってください。
| モード | 用意するもの | ブラウザの信頼 | 適した用途 |
|---|---|---|---|
| 1. プレーン HTTP(デフォルト) | 不要 | —(HTTP) | 信頼済みでセグメント化されたネットワーク(OT VLAN、制御盤) |
| 2. HTTPS、自己発行 CA | ドメイン + ワイルドカード DNS。クライアントに 1 つの CA ルートを配布 | CA を配布すれば信頼される | IT からの証明書を待たずに HTTPS を使いたい場合 |
| 3. HTTPS、企業証明書 | ドメイン + ワイルドカード DNS + 自社 CA のワイルドカード証明書 | 自動的に信頼される(貴社の組織 CA) | 社内 CA を持つ企業ネットワーク |
企業プロキシの背後で とは別物です。 そのページは、アプライアンスがアウトバウンドトラフィックのために貴社の企業 CA を信頼する(アプライアンス → クラウド、TLS 傍受型プロキシ経由)ことを扱っています。このページはその逆方向 — 貴社ネットワーク上のブラウザからアプライアンスに到達するインバウンドトラフィックです。両者は互いに独立しています。
モード 1 — プレーン HTTP(デフォルト)
得られるもの。 すべてがアプライアンスのアドレス上でプレーン HTTP により提供されます。
| インターフェース | アドレス |
|---|---|
| メインのアプライアンス UI | http://<APPLIANCE_HOST> |
| アプリ Web UI | http://<APPLIANCE_HOST>:<port> |
各アプリ UI は、自動的に割り当てられた独自のポート上で公開されます。IronFlock UI が各 UI の正確なリンクを表示します。アプリ UI はアプライアンスのログインの背後にとどまります — サインインしてそのデバイスに対して認可されていない限り、UI を開くとログインにリダイレクトされます(開放したい場合は、アプリごとにポートを公開としてマークできます)。
必要な作業。 ありません。これがデフォルトです — ローカルネットワーク上でアプライアンスの IP またはホスト名を使うだけです。DNS も証明書も、企業 IT の関与も不要です。
使いどころ。 信頼済みでセグメント化されたネットワーク上のアプライアンス — マシン/OT VLAN 上の制御盤など — で、プレーン HTTP が通常であり、アクセスがネットワークセグメント化と物理的セキュリティによって制御されている場合。
モード 2 — 自己発行 CA による HTTPS
得られるもの。 アプライアンスは組み込みの HTTPS イングレスを有効化し、自ら生成した証明書を使って、すべてを貴社ドメイン配下の HTTPS で提供します。稼働させるリバースプロキシも、配線し直す URL もありません。インストーラがすべて設定します。
| インターフェース | アドレス |
|---|---|
| メインのアプライアンス UI | https://<APPLIANCE_DOMAIN> |
| アプリ Web UI | https://<device>-<app>-<port>.<APPLIANCE_DOMAIN> |
| プラットフォームサービス | api. · auth. · login. · ws. · ide. · registry. <APPLIANCE_DOMAIN> |
必要な作業。
-
アプライアンスに解決するドメインを選び、それを使用するすべてのブラウザとデバイスに対して解決できるようにして、
APPLIANCE_HOSTとAPPLIANCE_DOMAINの両方をそれに設定します。アプライアンス自身が証明書を発行するため、任意の名前が使えます — 唯一の要件は、それが解決することです。簡単なテスト以上の用途では、自社の DNS 内にワイルドカードレコードを持つ、自分が管理する内部ドメイン(例:appliance.corp.example.com)を使用してください。隔離された、または DNS が制限されたアプライアンスネットワークは通常、デフォルトの<host-ip>.nip.io名が依存する公開のnip.ioサービスに到達できません。(そのデフォルトは、ネットワークがインターネットに到達できる環境では動作します — だからこそ開発マシンでは動作するのです。) -
ワイルドカード DNS を追加します。両方のレコードをアプライアンスホストの IP に向けます。
*.<APPLIANCE_DOMAIN>— アプリ UI およびすべてのサービスサブドメインをカバーします。<APPLIANCE_DOMAIN>(apex) — 名前によるメイン UI。
(
nip.ioのようなワイルドカード DNS サービスは、これらを自動的に解決するため、追加するレコードはありません — ただし、その外部サービスに到達できることが前提です。) -
--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 を生成し、それによって署名されたワイルドカード証明書を生成します。 -
CA ルートをクライアントマシンに配布します。
rootCA.crtを MDM で配布するか、各マシンの OS/ブラウザの信頼ストアに追加します。マシンがそれを信頼するまで、そのブラウザは警告を表示します。 -
1 年以内に更新します。 サーバー証明書は約 1 年に制限されます — ブラウザはそれより長寿命のものを拒否します。更新するには、証明書ディレクトリ内の
tls.crt/tls.keyを削除してインストーラを再実行します。同じ CA に対して新しい証明書を再署名するため、配布済みの信頼はそのまま機能し続けます。
デバイスはプレーン IP のパスにとどまります。 HTTPS に移行するのはブラウザ側だけです。接続されたデバイスは引き続きアプライアンスに IP 経由で到達するため、すべてのデバイスに CA をインストールする必要はありません。
使いどころ。 共有ネットワークで HTTPS を使いたいが、企業 IT からの証明書がない(あるいは待ちたくない)場合で、UI を開くマシンにルート CA を配布できる場合。
モード 3 — 企業証明書による HTTPS
得られるもの。 モード 2 と同じ、アプライアンス全体の HTTPS ですが、証明書は貴社組織の CA から発行され、そのルートはすべての管理対象マシンですでに信頼されています。ブラウザの警告はなく、配布するものもありません。デバイスもドメインへ移行します。
必要な作業。
- 自分が管理する内部ドメインを選び、
APPLIANCE_HOSTとAPPLIANCE_DOMAINをそれに設定します(例:appliance.corp.example.com)。ここでは、必ず自社ドメインでなければなりません — CA は所有するドメインに対してのみ証明書を発行するため、このモードではnip.io名は使えません。 - ワイルドカード DNS を追加 — モード 2 のステップ 2 と同様に、
*.<APPLIANCE_DOMAIN>と apex をアプライアンスホストの IP に向けます。 - 社内 CA から
*.<APPLIANCE_DOMAIN>のワイルドカード証明書を取得します。2 つの PEM ファイルとして:tls.crt(理想的にはフルチェーン)と、暗号化されていないtls.keyです。 - 証明書を付けてインストール:
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。 - 貴社 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の回避策はもはや不要になります。
使いどころ。 標準的な企業オンプレミスのパスです。貴社組織はすでに社内 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 とすべてのサービスサブドメインをカバーします。