Apache NiFi is a popular tool to simulate, implement and manage DataFlows for small Projects or even at Enterprise Scale. The various processors with their many functions combined with a simple and interactive UI makes it a very powerful platform for the purpose. Besides, having been written in Java, its usecases are very diverse from simulating standard ETL pipelines and executing Groovy Scripts to support for many other Open-Source Plugins such as those of HashiCorp, Azure, AWS, GCP, and Zoho.

Apache NiFi version at the time of writing - Apache NiFi v2.3.0

Platforms and Version

Platforms observed

• Executing Release Binaries on Linux/Windows/MacOS - Yes

• Docker - No

Version

• Apache NiFi version at the time of writing - Apache NiFi v2.3.0

Explanation of the issue:

While installing Apache NiFi, the NiFi server defaults to listening on localhost. Changing the default host in conf/nifi.properties causes issues and the server fails to listen on the specified hostname. Changing the default properties causes SNI Errors (Error Code 400) and NiFi web interface doesn’t load. Even trying to curl 127.0.0.1 may not work.

Solution

NiFi server uses HTTPS by default and uses a self-signed certificate that is typically configured with a Subject Alternative Name (SAN) that only includes localhost. This means connections will only be properly validated when accessing the server via https://localhost:port/nifi

Hence, besides the correct host configurations, a corresponding certificate has to be associated with the server so that it can validate connections coming from other sources. For the purpose of this article, let’s assume we want the server to validate connections coming through any network interface associated with the host machine

Steps to configure NiFi to listen on 0.0.0.0

1) Stop the NiFi Server

$ cd <nifi_directory>
$ ./bin/nifi.sh stop

Find the nifi.properties file

$ nano <nifi_directory>/conf/nifi.properties

Make sure the following properties are updated as shown below

# Site to Site properties
nifi.remote.input.host=0.0.0.0
nifi.remote.input.secure=true
nifi.remote.input.socket.port=10000

#############################################

nifi.web.https.host=0.0.0.0
nifi.web.https.port=8443
nifi.web.https.network.interface.default=
nifi.web.https.application.protocols=h2 http/1.1
nifi.web.jetty.working.directory=./work/jetty
nifi.web.jetty.threads=200
nifi.web.max.header.size=16 KB
nifi.web.proxy.context.path=
nifi.web.proxy.host=
nifi.web.max.content.size=
nifi.web.max.requests.per.second=30000
nifi.web.max.access.token.requests.per.second=25
nifi.web.request.timeout=60 secs
nifi.web.request.ip.whitelist=
nifi.web.should.send.server.version=true
nifi.web.request.log.format=%{client}a - %u %t "%r" %s %O "%{Referer}i" "%{User-Agent}i"

Generate the PKCS#12 certificates using keytool

Use keytool to generate new PKCS#12 certificates with appropriate Subject Alternative Names (SAN) in the certificates that actually enables it to accept connections from 0.0.0.0

$ cd <nifi_directory>/conf/
# copy the old keystore and trustore certificates
$ mv keystore.p12 keystore.p12-bak
$ mv truststore.p12 truststore.p12-bak
$ rm truststore.12 keystore.12
# use keytool to generate new certificates with appropriate Subject Alternative Names (SAN) in the certificates that actually enables it to accept connections from 0.0.0.0 (anywhere)

# Example for generating a new keystore with SANs
$ KEYSTORE_FILE="nifi.keystore.p12"
$ KEYSTORE_PASS="your_keystore_password"
$ KEY_ALIAS="nifi-server"
$ KEY_PASS="your_key_password"
$ HOSTNAME="0.0.0.0" # This will be the CN, but SANs will handle other addresses
$ IP_ADDRESS="YOUR_MACHINE_IP" # Replace with your actual IP

$ SUBJECT="CN=${HOSTNAME}, OU=NIFI, O=NIFI, L=Bengaluru, ST=Karnataka, C=IN"
SAN="DNS:localhost,IP:127.0.0.1,IP:${IP_ADDRESS}" # Add more DNS or IP entries as needed

$ keytool -genkeypair -alias "${KEY_ALIAS}" -keyalg RSA -keysize 2048 \
        -validity 365 -keystore "${KEYSTORE_FILE}" -storetype PKCS12 \
        -storepass "${KEYSTORE_PASS}" -keypass "${KEY_PASS}" -dname "${SUBJECT}" \
        -ext "SAN=${SAN}"

# If you also need a truststore (often the same for self-signed):
$ TRUSTSTORE_FILE="nifi.truststore.p12"
$ TRUSTSTORE_PASS="your_truststore_password"

$ keytool -exportcert -alias "${KEY_ALIAS}" -keystore "${KEYSTORE_FILE}" -storetype PKCS12 \
        -storepass "${KEYSTORE_PASS}" -rfc -file nifi.cert

$ keytool -importcert -alias "${KEY_ALIAS}" -file nifi.cert \
        -keystore "${TRUSTSTORE_FILE}" -storetype PKCS12 \
        -storepass "${TRUSTSTORE_PASS}" -trustcacerts -noprompt

$ rm nifi.cert # Clean up the temporary certificate file

Remember the passwords for the keystore and truststore certificates

Update the Certificate credentials in the NiFi Configuration

Go back into nifi.properties and update the certificate credentials as shown below

nano conf/nifi.properties

# security properties #
nifi.sensitive.props.key=1w7wlN6OlK8PFLWRWLWqyc1+avR4GU/l
nifi.sensitive.props.algorithm=NIFI_PBKDF2_AES_GCM_256

nifi.security.autoreload.enabled=false
nifi.security.autoreload.interval=10 secs
nifi.security.keystore=./conf/nifi.keystore.p12 #specify your path to the keystore certificate 
nifi.security.keystore.certificate=
nifi.security.keystore.privateKey=
nifi.security.keystoreType=PKCS12
nifi.security.keystorePasswd=thisismypass #specify your password for the keystore from the previous step
nifi.security.keyPasswd=thisismypass #specify the same password as for the keystore
nifi.security.truststore=./conf/nifi.truststore.p12 #specify your path to the truststore certificate
nifi.security.truststore.certificate=
nifi.security.truststoreType=PKCS12 #specify the format
nifi.security.truststorePasswd=thisismypass #specify the password for the truststore certificate from the previous step

As Additional Checks

Restart NiFi Server

$ cd <nifi_directory>
$ ./bin/nifi.sh restart

You should now be able to see the login page of NiFi

In summary, troubleshooting NiFi SNI errors demands careful attention to configuration alignment between NiFi and intermediary systems, ensuring certificate validity and consistency, and employing systematic diagnostic techniques to navigate the TLS handshake process effectively.

Encountered anything different? Share them with me in the comment section below!
If you liked the article, follow for more useful troubleshooting tips coming soon!