Signed SSL for ListenHTTP

[#1]

Hey guys,

I am running a NiFi cluster with signed SSLs. I am trying to secure ListenHTTP processor using a secureContext service but I ran into some issues. Hopefully the community can show me the error of my ways.

ListenHTTP setup:

Non-secured works. I can post data with:

curl -X POST --data 'Hello World!' URL:PORT/PATH

Secured processor:

Once the processor has been secured the only way I can send data to it is to include the certificate and privatekey. Otherwise, the POST will fail. A working curl would look like this for me.

curl -X POST --data 'Hello World! SSL Worked!' 'https:HOST:PORT/PATH' --cert ./meyCert --key ./PrivateKey

This functionality was not expected. Generally speaking, I expected to be able to send data to ListenHTTP using HTTPS without needing to include a certificate or privatekey. Is my configuration incorrect or is this functionality expected after securing ListenHTTP?

NiFi Signed SSL Certificate Configuration

I am including this as I think it may be part of the issue. To secure my NiFi cluster with signed SSL certs I requested signed certs from digicert. I combined my privatekey & server certificate into a single file. I then imported this file into a keystore. Next, combined my intermediate & root certificate into a single file, in this same order. I then imported the combined intermediate & root file into a truststore. This method successfully secured our NiFi in a clustered configuration.

[#2]

@Zack Atkinson

Using curl to make REST API call to https you have 2 options.

1. Do insecure connection/call with "-k" option - this option tells to curl that simply trust the server cert and do the post.

Ex: curl -k -X POST --data 'Hello World! SSL Worked!''https:HOST:PORT/PATH'

2. You don't need to provide private key - just public cert is good enough.

Ex: curl -X POST --data 'Hello World! SSL Worked!''https:HOST:PORT/PATH'--cert ./meyCert

[#3]

@amarnath reddy pappu, thank you for your reply. I agree that seems to be the logical path. What I see appears to differ from what the system is allowing. Attempting to perform this action fails. See the image below with verbose output. Any idea to explain this behavior?

[#4]

@Zack Atkinson

the curl call you are trying is incorrect. use cacert instead of cert

curl -X POST --data 'Hello World! SSL Worked!''https:HOST:PORT/PATH  '----cacert ./meyCert

My example:

curl -X GET https://c1111-node1.hdp.com:8443/#/login/local --cacert /tmp/knox.crt

Please mark my comment as correct answer if this solves your issue.

[#5]

Amarnath,

You are trying to resolve the issue of the untrusted server certificate if curl is run without the -k/--insecure option. That was not Zack's problem. To accept input from a client which is not identifying itself with a client certificate, the solution is to provide a StandardRestrictedSSLContextService with only the keystore-related options configured. Configuring the truststore-related options instructs the service to require a client certificate to negotiate a TLS handshake and allow the connection. This is what Zack was trying to avoid.

[#6]

Andy\Amarnath,

My question was initially why my expected outcome was not working and why this other format did work. Along the way, I believe my question was answered, assuming my understanding is correct. I did't want to dive to deep as I thought it may be outside the scope of my initial post. Since the conversation has gone that way tho, Andy is correct.

I did not understand the difference between 1-way SSL and 2-way SSL. Using 1-way SSL (keystore only) all HTTPS connections are accepted regardless if the source is who we are expecting or not. Using 2-way SSL only HTTPS connections are accepted but now we must verify who the source is by authenticating with a private key & server certificate that can be authenticated by my truststore.

My use case for this knowledge, is we are promoting projects between our Dev & Prod clusters. I wanted to ensure we had the correct security in place to proceed. The developers are wanting 1-way SSL but I lacked the knowledge at the time to make it work and only had 2-way. They were upset because this required more data to be sent via REST protocol using 2-way.

Now that I understand each protocol, I will not allow to them proceed to Production with their architecture without 2-way SSL. Originally, I was simply ignorant of how to setup 1-way SSL, without understanding the security hole it would make.

Thank you both for your time and effort in reviewing this concept.

[#7 · Accepted solution]

@amarnath reddy pappu

I kept playing with this issue and found a solution. For my SSL SecurityContext service, I was setting both truststore and keystore. For my need I only want to accept HTTPS data and deny HTTP data. Additionally, I do not care where it comes from in this context. If I leave off the truststore it will work. However, now anyone can send data to my endpoint. Definitely a plus and minus situation but now the understanding is there and I know how to proceed as the need arises.

[#8]

@Zack Atkinson not sure your answer is related to the question being asked - Am i missing some thing here?

Please check my comment below for answer to the curl call issue.

[#9]

Zack, glad you found a solution. I was coming to post this but wanted to verify something in my custom configuration wasn't affecting this before posting. We can probably improve the processor/controller service documentation to make this clearer and more intuitive. If you do decide you want client authentication and configure the truststore-related properties, you can also further restrict the authorized users via the Authorized DN Pattern processor property.