HTTPS 与证书

当已连接设备上的某个应用暴露出 Web 界面时，appliance 会通过其内置隧道使其可达。您可以选择浏览器如何访问 appliance——共有三种模式，从零配置到完全由企业签名。选择其中一种并按其步骤操作。

这与位于企业代理之后并不相同。 那一页讲的是 appliance 为出站流量信任您的企业 CA（appliance → 云端，经过拦截 TLS 的代理）。本页讲的是相反的方向——从您网络中的浏览器到 appliance 的入站流量。两者相互独立。

模式 1 — 纯 HTTP（默认）

您能得到什么。 一切都在 appliance 地址上通过纯 HTTP 提供：

每个应用 UI 都发布在各自自动分配的端口上；IronFlock UI 会显示每一个的确切链接。应用 UI 始终位于 appliance 登录之后——打开某个 UI 会重定向到登录页，除非您已登录并获得了对该设备的授权（在您希望某个端口开放的地方，可以按应用将其标记为公开）。

您需要做什么。 无需任何操作。这是默认设置——只需在本地网络上使用 appliance 的 IP 或主机名即可。无需 DNS，无需证书，无需企业 IT 参与。

何时使用。 位于受信任的、经过分段的网络上的 appliance——例如机器/OT VLAN 上的控制柜——在这种环境中纯 HTTP 是常态，访问由网络分段和物理安全来控制。

模式 2 — 使用自签发 CA 的 HTTPS

您能得到什么。 appliance 开启其内置 HTTPS 入口，并在您的域名下通过 HTTPS 提供一切服务——使用它自己生成的证书。既无需运行反向代理，也无需重新配置任何 URL；安装程序会将这一切自动接好。

您需要做什么。

1. 选择一个能解析到 appliance 的域名，使其对每一个将要使用它的浏览器和设备都能解析，并将 APPLIANCE_HOST 和 APPLIANCE_DOMAIN 都设置为它。由于 appliance 自己签发证书，任何名称都可以使用——唯一的要求是它能够解析。除了快速测试之外的任何用途，都请使用一个由您掌控的内部域名（例如 appliance.corp.example.com），并在您自己的 DNS 中为其添加通配符记录：隔离的或受 DNS 限制的 appliance 网络通常无法访问默认的 <host-ip>.nip.io 名称所依赖的公共 nip.io 服务。（在网络能够访问互联网的场景下，该默认值确实有效——这也是它在开发机上能工作的原因。）

2. 添加通配符 DNS，为该域名添加两条记录，均指向 appliance 主机 IP：

   • *.<APPLIANCE_DOMAIN> — 涵盖应用 UI 以及每一个服务子域名。
   • <APPLIANCE_DOMAIN>（顶级） — 按名称访问主 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 以进行无人值守安装）。appliance 会在 /opt/ironflock/certs/ca/rootCA.crt 生成一个本地 CA，并生成一张由它签名的通配符证书。

4. 向客户端机器分发该 CA 根证书。 通过您的 MDM 推送 rootCA.crt，或将其添加到每台机器的操作系统/浏览器信任存储中。在某台机器信任它之前，其浏览器会发出警告。

5. 在一年内续期。 服务器证书的有效期上限约为 1 年——浏览器会拒绝有效期更长的证书。要续期，请删除证书目录中的 tls.crt/tls.key 并重新运行安装程序；它会针对同一个 CA 重新签发一张新证书，因此您分发出去的信任仍然有效。

设备仍然走纯 IP 路径。 只有浏览器一侧转为 HTTPS。已连接的设备仍通过 appliance 的 IP 访问它，因此您无需在每台设备上安装该 CA。

何时使用。 您希望在共享网络上使用 HTTPS，但没有（或不想等待）来自企业 IT 的证书，并且您能够向将要打开该 UI 的机器推送一张根 CA。

模式 3 — 使用您的企业证书的 HTTPS

您能得到什么。 与模式 2 相同的全 appliance HTTPS——但证书来自您组织的 CA，其根证书在每一台受管机器上都已受信任。没有浏览器警告，也无需分发任何东西。设备也会一同迁移到该域名上。

您需要做什么。

1. 选择一个由您掌控的内部域名，并将 APPLIANCE_HOST 和 APPLIANCE_DOMAIN 设置为它（例如 appliance.corp.example.com）。此处必须是您自己的域名——CA 只会为您拥有的域名签发证书，因此 nip.io 名称在此模式下无法使用。
2. 添加通配符 DNS — *.<APPLIANCE_DOMAIN> 和顶级域名，均指向 appliance 主机 IP——与模式 2 第 2 步相同。
3. 获取一张通配符证书，用于 *.<APPLIANCE_DOMAIN>，来自您的内部 CA，形式为两个 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

   当文件发生变化时，appliance 会自动重新加载证书；重启只是为了立即应用它。除非您传入 --tls-cert，否则重新运行安装程序绝不会覆盖已有的证书。

设备也会迁移到该域名上。 由于该证书在整个机群范围内都受信任，设备流量——设备链接和容器镜像拉取——也会通过 TLS 走该域名，insecure-registries 变通方案不再需要。

何时使用。 标准的企业本地部署路径：您的组织已经运行着一个内部 CA，因此只需签发一次通配符证书，即可在各处受信任，无需任何逐机设置。

故障排查

某个应用 UI 链接打不开 / 连接被拒绝。 在纯模式下，应用 UI 位于 http://<host>:<port>——请确保您使用的是 IronFlock UI 中显示的确切链接（端口按应用分配），并确保网络上没有任何东西阻断该端口。

浏览器警告证书不受信任（在使用 --tls 之后）。 客户端尚未信任该证书的 CA。在模式 2 中，将 appliance 生成的 CA（/opt/ironflock/certs/ca/rootCA.crt）部署到客户端。在模式 3 中，确保客户端信任您的内部 CA 根证书。

证书已过期（自签发）。 自签发的服务器证书有效期约为一年（浏览器会拒绝有效期更长的证书）。请续期：删除证书目录中的 tls.crt/tls.key 并重新运行安装程序，以针对同一张仍受信任的 CA 重新签发——或改用来自您自己 CA 的 --tls-cert。

证书名称不匹配。 该证书不是所用域名的通配符证书。它必须涵盖 *.<APPLIANCE_DOMAIN>，且 URL 的域名必须与 APPLIANCE_DOMAIN 匹配。

某个子域名无法解析（在使用 --tls 之后）。 缺少通配符 DNS。添加一条指向 appliance 主机的 *.<APPLIANCE_DOMAIN> A 记录——它涵盖应用 UI 和每一个服务子域名。