Nifi:如何使ListenHTTP与SSL一起使用 [英] Nifi: how to make ListenHTTP work with SSL

问题描述

客观

由于Nifi通过HTTP与其他工具集成，我必须公开面向 ListenHTTP 处理器.在所有3种环境中，API网关对我来说都太昂贵了.因此，我关闭了外部网络的所有VM入口端口( ListenHTTP 所需的端口除外).

问题

使用 StandardRestrictedSSLContextService 配置的 ListenHTTP 无效.如果没有SSL，它可以工作，但是不安全.

  user $ curl -X POST -H"Content-Type:application/json"-数据测试"https://localhost:7070/test％总计％接收的％Xferd平均速度时间时间时间当前Dload上传总花费左手速度0 0 0 0 0 0 0 0-:-:--:-:--:-:-0curl:(60)SSL证书问题:自签名证书此处有更多详细信息:https://curl.haxx.se/docs/sslcerts.htmlcurl无法验证服务器的合法性，因此无法建立与其的安全连接.要了解有关这种情况的更多信息，以及如何修复，请访问上面提到的网页......user $ curl -X POST -H"Content-Type:application/json"-数据测试"--cacert cacerts.jks https://localhost:7070/testcurl:(77)错误设置证书验证位置:CAfile:cacerts.jksCApath:无 

问题

如何使 ListenHTTP 与SSL证书一起使用?我在做什么错了?

更详细的问题:

1. 是否应该将cacerts.jsk复制到发出查询的计算机上?据我了解， StandardRestrictedSSLContextService 将验证客户端是否在TrustStore中具有证书.
2. 如果我只需要使用 ListenHTTP 处理器保护单个端口，则不需要.

解决方案

您使用的 SSLContextService 可能不包含由可公开访问的证书颁发机构(CA)签名的证书例如(仅出于解释目的；不认可)，例如Comodo，Verisign，Let's Encrypt等.

由这些CA签署的证书通常会被任意客户端自动信任，因为构建客户端的人(用于浏览器的Java，Google/Microsoft/Mozilla/Apple，用于操作系统的Microsoft/Apple/Linux Distro)已抢先包括了这些顶级证书，客户端 truststore 中的级别的公共证书.您创建的 cacerts.jks 信任库采用Java密钥库格式，而 curl 却无法理解.您可以使用此处的命令，但这只会解决眼前的问题，即允许具有任意信任库的 curl 进行连接.

如果您希望通用外部客户端能够通过TLS连接，则需要使用NiFi密钥库中的证书，该证书由著名的CA 签名.您可以使用任何商业CA来实现此目的，但是让我们的加密确实免费提供了这项服务，并且使用非常广泛.使用由CA签名的证书后，任何*客户端都将可以连接.

如果这仅用于内部/企业用途，并且所有允许的客户端都可由您控制，那么您可以使用自签名证书(就像您按照Simon的指示现在所做的那样)，然后将公共证书导出到您的其他客户端需要的任何格式，以便与此特定服务器建立信任.从理论上讲，您还可以强制每个尝试连接的客户端也需要出示服务器(NiFi)可以验证的证书-这称为相互认证TLS ，并且因为只有经过身份验证的客户端才能向该服务器发出请求，所以添加了另一层安全性.如果您选择这样做，那就是 ListenHTTP 中的 SSLContextService 也将需要一个信任库组件的情况.

在不知道您的明显情况的情况下，我会强烈建议您选择选项1(已签名的证书).

Objective

Because of Nifi integration with other tools through HTTP, I have to make ListenHTTP processor public facing. API Gateway on all 3 environments is too expensive for me. So I closed all VM ingress ports (except the one needed for ListenHTTP) for outer networks.

Issue

My configuration of ListenHTTP with StandardRestrictedSSLContextService doesn't work. Without SSL it worked, but was unsecure.

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

Question

How to make ListenHTTP work with SSL certificates? What am I doing wrong?

More detailed questions:

1. Should I copy cacerts.jsk to the machine from which I issue the query? As far as I understand, StandardRestrictedSSLContextService will verify if the client has certificate in TrustStore.
2. If I need to protect only a single port with ListenHTTP processor - then I don't need nifi.security.needClientAuth property or all environment variables defined at "Standalone Instance, Two-Way SSL" section, right? I'm little bit confused because both Docker Image and StandardRestrictedSSLContextService contains the same configs, i.e. KEYSTORE_TYPE.

Already done

1. I have a general idea about KeyStore & TrustStore from this question and the documentation.
2. I have launched Nifi Docker container v1.10.0 with up & running ListenHTTP processor on 7070 port.
3. I have created keystore.jks and cacerts.jks files due to the instruction inside Nifi container.
4. I have configured ListenHTTP to use StandardRestrictedSSLContextService controller with the following configs: .

解决方案

The SSLContextService you're using probably doesn't contain a certificate which is signed by a publicly-accessible certificate authority (CA) like (for explanation purposes only; not endorsement) Comodo, Verisign, Let's Encrypt, etc.

Certificates signed by those CAs are generally trusted automatically by arbitrary clients because whoever builds the client (Java, Google/Microsoft/Mozilla/Apple for a browser, Microsoft/Apple/Linux Distro for the OS) has preemptively included those top-level public certs in the truststore of the client. The truststore you created cacerts.jks is in Java Keystore format, which curl doesn't happen to understand. You can export the public certificate from that keystore to a standalone file in PEM format using the commands here, but that will only solve the immediate problem of allowing curl with an arbitrary truststore to connect.

If you want generic external clients to be able to connect over TLS, you'll need to use a certificate in NiFi's keystore that is signed by a well-known CA. You can use any commercial CA for this purpose, but Let's Encrypt does offer this service for free and is very widely used. Once you are using a certificate signed by a CA, any* client will be able to connect.

If this is for internal/enterprise use only, and all allowed clients are controllable by you, then you can use a self-signed certificate (like you are doing now if you followed Simon's instructions), and export the public certificate to whatever format your other clients need in order to establish trust with this particular server. Theoretically, you could also enforce that each client attempting to connect also needs to present a certificate that the server (NiFi) can verify -- this is called mutual-authentication TLS and adds another layer of security because only authenticated clients will be able to make requests to this server. If you choose to do so, that's when the SSLContextService in ListenHTTP would need a truststore component as well.

Without knowing your explicit situation, I would heavily recommend option 1 (the signed cert).

这篇关于Nifi:如何使ListenHTTP与SSL一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！