security - 尼菲 : how to make ListenHTTP work with SSL

Question

客观的
由于 Nifi 通过 HTTP 与其他工具集成，所以我必须使 ListenHTTP处理器面向公众。所有 3 个环境中的 API 网关对我来说都太贵了。因此，我关闭了外部网络的所有 VM 入口端口(ListenHTTP 所需的端口除外)。
问题
我的配置ListenHTTP与 StandardRestrictedSSLContextService不起作用。如果没有 SSL，它可以工作，但不安全。

user$ curl -X POST -H "Content-Type: application/json" --data "test" https://localhost:7070/test
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

.....

user$ curl -X POST -H "Content-Type: application/json" --data "test" --cacert cacerts.jks  https://localhost:7070/test
curl: (77) error setting certificate verify locations:
  CAfile: cacerts.jks
  CApath: none

问题
制作方法 ListenHTTP使用 SSL 证书？我究竟做错了什么？
更详细的问题:

我应该将 cacerts.jsk 复制到发出查询的机器上吗？据我了解，StandardRestrictedSSLContextService将验证客户端是否在 TrustStore 中有证书。

如果我只需要使用 ListenHTTP 保护单个端口处理器 - 那么我不需要 nifi.security.needClientAuth "Standalone Instance, Two-Way SSL" 中定义的属性或所有环境变量部分，对吧？我有点困惑，因为 Docker Image 和 StandardRestrictedSSLContextService包含相同的配置，即 KEYSTORE_TYPE。

已经完成了

我对 this question 中的 KeyStore 和 TrustStore 有一个大致的了解和 documentation .

我已启动Nifi Docker container v1.10.0启动并运行ListenHTTP处理器在 7070 端口。

由于 instruction，我创建了 keystore.jks 和 cacerts.jks 文件在 Nifi 容器内。

我已经配置了ListenHTTP使用 StandardRestrictedSSLContextService具有以下配置的 Controller :
.

Answer 1

SSLContextService您使用的可能不包含由可公开访问的证书颁发机构 (CA) 签名的证书，例如(仅用于解释目的；不认可)Comodo、Verisign、Let's Encrypt 等。
由这些 CA 签名的证书通常会被任意客户端自动信任，因为构建客户端的人(Java、Google/Microsoft/Mozilla/Apple 用于浏览器，Microsoft/Apple/Linux Distro 用于操作系统)已经抢先包含了这些顶级公共(public)证书在客户端的信任库中。您创建的信任库 cacerts.jks采用 Java Keystore 格式，curl碰巧不明白。您可以使用 the commands here 将公共(public)证书从该 keystore 导出到 PEM 格式的独立文件中。 ，但这只会解决允许 curl 的直接问题。使用任意信任库进行连接。
如果您希望通用外部客户端能够通过 TLS 连接，则需要使用 NiFi keystore 中由知名 CA 签名的证书。您可以为此目的使用任何商业 CA，但 Let's Encrypt确实免费提供这项服务，并且使用非常广泛。一旦您使用由 CA 签名的证书，任何*客户端都可以连接。
如果这仅供内部/企业使用，并且所有允许的客户端都可以由您控制，那么您可以使用自签名证书(就像您现在按照 Simon 的说明做的那样)，并将公共(public)证书导出为您的任何格式其他客户端需要与此特定服务器建立信任。从理论上讲，您还可以强制每个尝试连接的客户端还需要提供服务器 (NiFi) 可以验证的证书——这称为 双向认证 TLS 并增加了另一层安全性，因为只有经过身份验证的客户端才能向该服务器发出请求。如果您选择这样做，那就是 SSLContextService在 ListenHTTP还需要一个信任库组件。
在不知道您的明确情况的情况下，我强烈推荐选项 1(签名证书)。