Support Questions
Find answers, ask questions, and share your expertise

Signed SSL for ListenHTTP

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.

1 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.

View solution in original post

8 REPLIES 8

@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

@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?

86518-nifitempimage.png

@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.

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.

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.

@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.

@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.

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.

; ;