Lorawan-stack: 同一台机器上的apache + ttn堆栈+letsencrypt acme证书获取问题

创建于 2019-12-19 · 5评论 · 资料来源: TheThingsNetwork/lorawan-stack

感谢您提交错误报告。请填写下面的模板，否则我们将无法处理此错误报告。

概括

在 ttn 机器上安装和启用 apache 时出现问题（收听 80/443）。
TTN 控制台在 80/443 端口上被阻止并在 1885,8885 端口上工作。

在这种情况下，ttn 无法获取/更新证书。
这是非常常见的情况，如果有人想将 TTN 堆栈和某些 DB/Web 应用程序放在同一设备上。

https://github.com/TheThingsNetwork/lorawan-stack/issues/1731

TTN 显示错误：缺少证书/或主机不在白名单中。

重现步骤

我们如何重现问题？

1) 当 apache 处于活动状态时（侦听 80、443）端口配置 - ttn 堆栈不允许启用 80、443 端口（80,443 必须在 docker-compose.yml 中 # 使用 - 端口 1885、8885）。在此（docker-compose 没有获得letsencrypt 证书）。

docker-compose.yml文件：

   ports:
(hashed)      - '80:1885'
(hashed)     - '443:8885'
      - '1882:1882'
      - '8882:8882'
      - '1883:1883'
      - '8883:8883'
      - '1884:1884'
      - '8884:8884'
      - '1885:1885'
      - '8885:8885'
      - '8886:8886'
      - '1887:1887'
      - '8887:8887'
      - '1700:1700/udp'
    env_file: '.env'

.env文件将端口移至 8885 而不是 443：

TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com:8885/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com:8885/oauth

TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com:8885/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3

TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com:8885/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com:8885/oauth/token

TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com:8885/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com:8885/api/v3

2) 当我们：
停止 apache（服务 apache2 停止）
重新配置 ttn-stack 以启用（80、443 端口 - 删除（哈希））
使用 Web 浏览器连接到主子域，它成功获取证书（在 80/443 端口上）

docker-compose.yml文件：

  ports:
      - '80:1885'
      - '443:8885'
      - '1882:1882'
      - '8882:8882'
      - '1883:1883'
      - '8883:8883'
      - '1884:1884'
      - '8884:8884'
(hashed)      - '1885:1885'
(hashed)     - '8885:8885'
      - '8886:8886'
      - '1887:1887'
      - '8887:8887'
      - '1700:1700/udp'
    env_file: '.env'

.env文件标准端口使用 443 - 在这种情况下 ttn 获取 letencrypt 证书

TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com/oauth


TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com/api/v3

TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com/oauth/token

TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com/api/v3

3) 现在，如果我们更新了证书，我们可以切换回第一个配置（apache 使用的端口 80/443，控制台使用 1885/8885） - 并在https://subdomain.domain.com上成功打开控制台：8885 /.

你现在看到了什么？

请粘贴终端输出，上传日志（作为 .txt）或上传屏幕截图。

...

你想看什么？

如果适用，请添加一些示例或模型。

...

环境

您的环境：操作系统/浏览器/网关/设备/...？版本？ ID/EUI？如果适用，粘贴“ttn-lw-cli version”或“ttn-lw-stack version”的输出。

...

您建议如何实施？

有没有办法在同一台机器上同时配置 ttn 和 apache？或强制让加密以在不同的端口上获得认证？

你能自己做这个并提交一个拉取请求吗？

如果您需要这方面的帮助，也可以@提及专家。

...

documentation

资料来源

ecities

最有用的评论

当您在反向代理后面运行 The Things Stack 时，您必须在配置中完全禁用 TLS，并使代理负责终止所有 TLS 连接（不仅是 HTTP，还有 gRPC、MQTT 等）。我想我们可以记录如何禁用 The Things Stack 的所有 TLS 侦听器，以及需要在反向代理中映射哪些端口。

我认为我们可以期望这样做的人已经知道他们的代理是如何工作的，所以我认为我们不应该用 apache/nginx/haproxy/envoy/etc 专门记录如何做到这一点。

htdvisser 于 2019-12-19

👍2

所有5条评论

我认为我们可以期望这样做的人已经知道他们的代理是如何工作的，所以我认为我们不应该用 apache/nginx/haproxy/envoy/etc 专门记录如何做到这一点。

htdvisser 于 2019-12-19

👍2

嗨@htdvisser ，感谢您的回复。

我在具有公共/静态 IP 地址（基于 lte）的本地计算机上进行了测试 - 我不知道网络的结构是什么。
我还在互联网端直接在 VPS (ovh.eu) 上进行了测试 - 根据提供商的说法，它没有代理和防火墙（只有一些 DoS）。

两种变体都需要相同的（每个客户端/ip 站的标准 80/443 端口上的证书初始化）。
稍后控制台可以切换到其他端口（1885/8885）。

还有另一个关于VPS 或任何公共/静态 IP设备的问题 - 无论网络结构如何。

我看了一会儿“控制台日志屏幕”，TTN 堆栈报告了很多“黑客活动试验”（我们在屏幕上只看到对标准 http/htts 端口的网络攻击）。域/子域只有 dns 记录，并没有用于机器人/搜索引擎可能发现的网页。我假设黑客机器人会搜索响应设备的所有静态 IP4 地址，迟早会发现设备并被黑客机器攻击。因此，很容易让任何服务器忙于对已知 http/https 端口进行大规模攻击，即使它们 100% 是安全的。

我认为不将 80/443 端口用于控制台/Web 界面是非常合理的，并且有可能为 TTN 堆栈控制台更改它们。它用于管理目的（非公开）并且管理员知道此设置。

唯一的问题是：
计划 A)我们如何在不同的端口上自动创建/刷新 acme/letsencrypt 证书？
计划 B)是否可以自动执行上述手动过程，至少在此处描述的几个已知主机（例如静态 ip）进行管理？

ecities 于 2019-12-19

ACME 的 HTTP-01 和 TLS-ALPN-01 挑战的规范要求使用端口 80/443。如果您使用不同的端口，则无法使用这些质询获取或更新证书。

您可以尝试使用 DNS-01 质询和 certbot 之类的工具（这超出我们文档的范围）或从付费证书颁发机构（也在我们的文档范围之外）请求 ACME 证书。

当您拥有此类证书时，您可以根据“自定义证书”说明配置 The Things Stack： https: //thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates 并使用以下环境：

TTN_LW_TLS_SOURCE=file
TTN_LW_TLS_CERTIFICATE=/path/to/cert-chain.pem
TTN_LW_TLS_CERTIFICATE=/path/to/key.pem

htdvisser 于 2019-12-19

👍1

我创建了问题https://github.com/TheThingsNetwork/lorawan-stack/issues/1760来记录如何配置 The Things Stack 以在 TLS 终止代理后面运行。

我创建了问题https://github.com/TheThingsNetwork/lorawan-stack/issues/1761来记录如何在 The Things Stack 中配置外部请求的证书。

htdvisser 于 2019-12-19

谢谢

ecities 于 2019-12-19

此页面是否有帮助？

0 / 5 - 0 等级

Lorawan-stack: 同一台机器上的apache + ttn堆栈+letsencrypt acme证书获取问题

概括

重现步骤

你现在看到了什么？

你想看什么？

环境

您建议如何实施？

你能自己做这个并提交一个拉取请求吗？

最有用的评论

所有5条评论

相关问题