Your truststore has two trustedCertEntries -- one for the server cert and one for the client. I don't know what browser you are using to attempt to access the UI, so I don't know why it is not prompting you for a client certificate. I recommend you use the following OpenSSL command to attempt a client connection from the command line and either verify that it successfully negotiates a mutually-authenticated handshake or fails and you can provide more error output. The command is on this Gist I have published. $ openssl s_client -connect <host:port> -debug -state -cert <path_to_your_cert.pem> -key <path_to_your_key.pem> -CAfile <path_to_your_CA_cert.pem> If you do not have your various certificates and keys in the correct format to use with this command, sections 2, 3, and 6 will allow you to export them to the right format. It also appears from your earlier comment that you generated the client certificate and then stored it in your keystore. This is unnecessary and incorrect. The various keystores and certificates should be as follows: Keystore Used by NiFi application Contains private key and public certificate (single PrivateKeyEntry entry) used by the server to identify itself The public certificate should contain multiple certificates in the chain (in the same entry) to reach a trusted signing certificate (either one you control and manually trust, or a publicly-trusted certificate) Truststore Used by the NiFi application Contains arbitrary number of trustedCertEntry entries (all public certificate(s) only) to verify "peer" certificates (either incoming client connections or connections NiFi makes to external resources, i.e. to ingest data from an HTTPS site) Client certificate Usually stored in PKCS12 keystore ( *.p12 ) Must contain the private key and public certificate with CN=<user name> Certificate must be explicitly trusted or signed by known trusted certificate in truststore Certificate must have complete chain in order for truststore to build certificate validation path ... View more

@Karthik is correct that the provenance, content, and flowfile repositories are stored on disk unencrypted. Current recommendations are to restrict access to said repositories using OS-level access control (e.g. POSIX) and to use encrypted storage volumes. There is an existing security feature roadmap entry for transparent data encryption of the various repositories so that the values are never written to the file system in an unencrypted form. Obviously there are performance implications to take into consideration when developing this feature and an admin choosing to enable it. Just because the repository format on disk is "human unreadable" binary does not preclude the security concerns here -- an arbitrary process with OS permission can read those files, and the serialization logic is open source. ... View more

You did not answer my question about what type of error you are actually encountering. The setting nifi.security.needClientAuth applies only to cluster communications and has no bearing on UI/API access. The Admin Guide discusses this. If you did not configure LDAP or Kerberos as a user authentication mechanism, then you will definitely need a client certificate in order to access the secured UI. If you manually generated your keystore and truststore, you will need to do the same with the client certificate and have it be signed by a key that is loaded into your truststore. You can also use the TLS Toolkit that is provided with NiFi to generate all of the necessary files. There are many step-by-step tutorials on this site and others. An easy one is here. Do not load the server certificate identifying the NiFi application into the browser to act as a client certificate. They are different, and exposing the private key of the NiFi certificate is not a good idea. ... View more

Did you load your client certificate into the browser? What do you mean you are not able to access the site? Are you getting a TLS error and nothing comes up, or are you getting a NiFi message that says you are not authorized? You need to ensure that the DN of your client cert is in conf/authorizers.xml as the Initial Admin Identity and that it matches the user defined in conf/users.xml . You can find more information by tailing $NIFI_HOME/logs/nifi-app.log and $NIFI_HOME/logs/nifi-user.log . ... View more

In Windows you need to prepend the file path with " file:/// ". Try " file:///F:/Tools/HDF-2.0.1.0/nifi/conf/nifidev.keystore.jks ". ... View more

Also ensure that the keystore files have the correct permissions to be readable by the user running NiFi. ... View more

The error " org.xml.sax.SAXParseException; systemId: file:/F:/Tools/HDF-2.0.1.0/nifi/./conf/users.xml; lineNumber: 1; columnNumber: 1; Premature end of file. " indicates that the users.xml file was either empty or contained only comments. ... View more

@slachterman you are correct and I have updated my answer to reflect this. Thanks. ... View more