如何配置在Google Cloud上启用SSL的Apache NIFI以连接https负载均衡器运行状况检查

时间:2019-11-15 19:59:17

标签: ssl https google-cloud-platform apache-nifi tls1.2

我在google cloud上安装了带有ambari(版本:Nifi 1.9.0,AMBARI 2.7.3,HDF 3.4.1.1-4)的apache nifi。在三个节点实例组的前面有一个https负载均衡器。前端使用提供的标准Google加密证书,以https终止。后端是https,指向nifi正在侦听的三个节点实例组上的端口,并且已启用ssl。在启用ssl之前,我能够连接到后端的http nifi。启用ssl后,tcpdump会显示相应nifi节点与负载均衡器运行状况检查IP范围之间的tls握手错误证书错误。

我正在寻找如何配置nifi,以便nifi发送整个证书链并通过运行状况检查成功完成握手。

现在,我的nifi ssl配置节点实体是: CN =节点1的完整合格域名(FQDN),OU = NIFI CN =节点2的完整合格域名(FQDN),OU = NIFI CN =节点3的完整合格域名(FQDN),OU = NIFI ->

我已经从TinyCert创建并下载了证书,并生成了每个nifi节点上的keystore.jks和truststore.jks文件。

密钥库包含两个条目:

别名:cert         创建日期:2019年10月31日         条目类型:trustedCertEntry         所有者:CN =节点1的FQDN,OU = NIFI,O = Staq,L =巴尔的摩,ST = Md,C = US         发行者:CN = Staq CA,OU =安全数字证书签名,O = Staq,L =巴尔的摩,ST = Md,C = US

    Alias name: cacert
    Creation date: Oct 31, 2019
    Entry type: trustedCertEntry
    Owner: CN=Staq CA, OU=Secure Digital Certificate Signing, O=Staq, L=Baltimore, ST=Md, C=US
    Issuer: CN=Staq CA, OU=Secure Digital Certificate Signing, O=Staq, L=Baltimore, ST=Md, C=US

如何使运行状况检查成功与nifi节点进行tls握手?


The Google load balancer back end is an instance group with three nodes, nifi1, nifi2, nifi3, where nifi is running on each and listening on port 9091. 
The backend service is protocol https, named port https, the instance group is entered for the backend and port number is 9091. 
When I sit on nifi1 and curl the internal ip:9091 of nifi2, in a tcpdump of eth0 activity , I get a fatal error 'Unknown CA' in the handshake from nifi1 to nifi2. In the same tcpdump I see the healch check trying to connect to nifi2 ip:9091, from the range of IP addresses health check uses, and it gets a fatal error during the tls handshake, 'Bad Certificate'.  

I went to TinyCert.org, and created a certificate for each node, so the CN for each node is the FQDN(fully qualified domain name) , the OU is NIFI, and the rest of the fields are the same. The Certificate Authority CN is Staq CA, the OU is 'Secure Digital Certificate Signing', and the rest of the fields are the same. So I have a cacert.pem , and each node has a set of files: 
certchain.pfx,
cert.pfx,
key.dec.pem, 
key.enc.pem, 
certchin.pem, 
and cert.pem.

    openssl verify -CAfile ../cacert.pem cert.pem 
    cert.pem: OK

For NIFI, I generated a keystore.jks and a truststore.jks file, and loaded these to /etc/security/nifi-certs,  and put this location in the 
nifi.properties file. 
                nifi.web.http.host=
                nifi.web.http.network.interface.default=
                nifi.web.http.port=
                nifi.web.https.host=FQDN (same as used in CN name) 
                nifi.web.https.network.interface.default=
                nifi.web.https.port=9091


The login-identity-providers.xml is empty. 

I used the following to create the truststore and keystore.

    openssl pkcs12 -export -in cert.pem -inkey key.enc.pem -out abc.pkcs12 

    Enter pass phrase for key.enc.pem:    PASSPHR
    Enter Export Password:                PASSWD

    keytool -importkeystore -srckeystore abc.pkcs12 -srcstoretype 
    PKCS12 -destkeystore keystore.jks -deststoretype jks 
    Importing keystore abc.pkcs12 to keystore.jks...
    Enter destination keystore password:  PASSWD
    Re-enter new password:                PASSWD
    Enter source keystore password:       PASSWD
    Entry for alias 1 successfully imported.

    keytool -import -file ../cacert.pem -alias cacert -keystore 
    truststore.jks -storepass 
    trust this certficate: yes

0 个答案:

没有答案