Why won't HandleHTTPRequest bind to a secure (SSL) port?

[#1]

I have HandleHTTPRequest running without encryption on port 80. This works fine.

I would like another HandleHTTPRequest running on 443, using my signed certificate. I have verified to the best of my ability that the certificate store is valid, and the SSLContextService is happy to start with it. Additionally, the NiFi interface is being served over HTTPS on port 8443 without issue.

When I try to start the processor, it "starts" with repeated errors every few seconds starting that it failed to start. Looking in the log, it says the port is in use. A NetStat shows the NiFi process as the one listening on 443.

Things checked/tried:

* port is not in use before starting NiFi processor

* ports other than 443 also fail

* disabling secure web interface doesn't have an impact

* fresh instance booted from 1.3.0 Docker image has no impact

* context service won't start if known invalid data is entered (it's able to read the certificate store when given correct password and starts without issue).

What would cause it to open a listener on a port and then immediately fail to bind the processor to that port? Is there anything I'm missing?

[#2]

@Justin R.

This sounds odd. In Linux, non-root users cannot listen on ports bellow 1024, so are you running NiFi as root? That wouldn't be advisable.

What is the complete stacktrace of the error? Maybe there is another nifi processor listening?

[#3]

Yes, running as root, mainly to troubleshoot this issue. This is just our pre-production environment, it's not publicly accessible, we have a configuration backup in place, and it's a VM that can be tossed, so we're not terribly worried about it. We've tried high ports (4430, 4043, 44300, 44003...) as both a user and as root, but neither works. I failed to grab the stack trace last week, and we got a working solution in place using an nginx server functioning as a proxy, but I may go down the route of recreating it to see if we can't figure out why it's doing what it's doing.

[#4]

@Justin R.

Is this a NiFi cluster installation with multiple nodes running on the same host?

If that is the case, which ever node manages to bind to the port first wins, all other nodes on same host will report that port is already in use.

Matt

[#5]

Not a cluster, it's a single node on a single VM. It's definitely the only NiFi process on the machine and that process is "bound" to the port, even if Java is convinced otherwise.

[#6]

Hi @Justin R., where you able to resolve this ?

[#7]

I had the same problem because I would like to reuse keystore created to securized Nifi UI and because of the usage dedicated to Nifi (TLS including client authentication), it can't be simply use to activate TLS.

Symptom: java.net.BindException: Address already in use: bind

Clue: If you search for the the first exception, in my case, it was "java.security.UnrecoverableKeyException: Cannot recover key"

So I guess, the server can't get the key even if SSLContext starts correctly and, as the server starts anormally, Nifi tries to restart and then a Bind exception raises.

I just regenerated a very classic jks store for server authentication usage using keytool -genkey ... and all went like a charm ...

Hope that help

Jean-Louis

,

I had the same problem because I would like to reuse keystore created to securized Nifi UI and because of the usage dedicated to Nifi (TLS including client authentication), it can't be simply use to activate TLS.

Symptom: java.net.BindException: Address already in use: bind

Clue: If you search for the the first exception, in my case, it was "java.security.UnrecoverableKeyException: Cannot recover key"

So I guess, the server can't get the key even if SSLContext start correctly !!

I just regenerated a very classic jks store for server authentication usage using keytool -genkey ... and all went like a charm ...

Hope that help