Alvin, The encrypted content repository feature is actively being worked on. As a rule, we cannot make claims about the delivery dates or versions of active development features. Hope this helps. If you have compliance requirements that sensitive data (such as PII, PCI/payment details, EPHI, etc.) is never stored on disk in plaintext, you can explore using the volatile content repository, but be aware there is the risk of data loss in the event of power failure, and this applies to all content objects, not just the sensitive records. With Apache NiFi 1.3.0, you can also use the RecordReader and RecordSetWriter approach -- while the EncryptedRecordReader and EncryptedRecordSetWriter controller services are not yet available, you could use a custom ScriptedRecordReader and ScriptedRecordSetWriter to decrypt and re-encrypt on the fly. The intermediate "record" object is never persisted to disk, so at no point would the plaintext data be written outside of volatile memory regardless of the content repository implementation. ... View more

What issue do you get when using openssl s_client ? You should definitely be able to connect using s_client, although you may need to provide -CAfile option to trust the issued server certificate and -cert and -key options to provide a client certificate as below: openssl s_client -connect nifi.nifi.apache.org:9443 -debug -state -CAfile conf/nifi-cert.pem -cert conf/client.pem -key conf/client.key As for the handshake_failure issue, this may be because: The certificate has expired or is invalid The provided keystore or key password is incorrect and the controller service cannot access the keystore The server and client cannot agree on a suitable cipher suite during negotiation Diagnosing with s_client is definitely the correct tool. You can also enable TLS debugging via the bootstrap.conf file with the line: java.arg.15=-Djavax.net.debug=ssl,handshake This output will be in logs/nifi-bootstrap.log . ... View more

The error is saying that one node in the cluster is attempting to make a heartbeat connection to the other node, but it is not providing a valid client certificate in order to authenticate itself during the TLS handshake negotiation. There are a few possible reasons for this error: The node is not sending the client certificate. Ensure that nifi.security.needClientAuth=true and nifi.cluster.protocol.is.secure=true are present in your nifi.properties file. The truststore on the receiving node does not contain the public key certificate of the connecting node. When you followed the instructions from that link, how did you generate the respective certificates? Using the Apache NiFi TLS Toolkit as described by Pierre should ensure that all node certificates are signed by the same CA and that the CA is imported into the common truststore. If you manually generated your certificates, ensure that they are trusted on each node (you can do this with OpenSSL's s_client tool). ... View more

Currently, NiFi supports encrypting/decrypting data through the EncryptContent processor, but the pre/post state of the data would still be stored in plaintext in the content repository. In general, transparent disk encryption/OS-level data encryption is recommended in conjunction with strict OS-level/POSIX access controls. There is a current effort to provide encrypted implementations of the flowfile (attribute), content, and provenance repositories. As Dan mentioned, a combination of encrypted payload and plaintext metadata for routing can work very well if the payload does not need to be processed/transformed inside NiFi. ... View more