Skip to main content
mslnrd
mslnrd
Gold ⭐️
August 1, 2023
Solved

NiFi Registry HTTPS Setup Giving SSL_ERROR_BAD_CERT_ALERT

Hello,

I am trying to setup a HTTPS on NiFi Registry and am receiving SSL_ERROR_BAD_CERT_ALERT when attempting to access the URL after loading the certificates.

The way I am setting it up is that I create a CSR, have the CA sign it (AD Domain Controller) and import that certificate into the keystore.  

 

I have generated the keystore, the truststore imported the certificates, and when I restart the NiFi Registry service the logs show no errors so I am not sure what I am doing wrong.

 

Below are some sanitized outputs of some commands I've ran to show what I could potentially have done wrong.

Curl Output:

curl --cert-type P12 --cert ./keystore.p12:Password --cacert /root/ssl/ADcerts/ad1-ca.cer -v https://nifiregistry.our.network.com:8443/nifi-registry
*   Trying 123.4.56.78:8443...
* Connected to nifiregistry.our.network.com (123.4.56.78) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /root/ssl/ADcerts/ad1-ca.cer
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=Country; ST=State; L=City; O=Org; OU=OrgUnit; CN=nifiregistry
*  start date: Jul 31 20:04:43 2023 GMT
*  expire date: Jul  6 17:37:31 2038 GMT
*  subjectAltName: host "nifiregistry.our.network.com" matched cert's "nifiregistry.our.network.com"
*  issuer: DC=com; DC=network; DC=our; CN=AD1-CA
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /nifi-registry HTTP/1.1
> Host: nifiregistry.our.network.com:8443
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 01 Aug 2023 17:20:26 GMT
< Content-Security-Policy: frame-ancestors 'self'
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31540000
< Location: https://nifiregistry.our.network.com:8443/nifi-registry
< Content-Length: 0
<
* Connection #0 to host nifiregistry.our.network.com left intact

Keystore -V

curl --cert-type P12 --cert ./keystore.p12:Password --cacert /root/ssl/ADcerts/ad1-ca.cer -v https://nifiregistry.our.network.com:8443/nifi-registry
*   Trying 123.4.56.78:8443...
* Connected to nifiregistry.our.network.com (123.4.56.78) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /root/ssl/ADcerts/ad1-ca.cer
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=Country; ST=State; L=City; O=Org; OU=OrgUnit; CN=nifiregistry
*  start date: Jul 31 20:04:43 2023 GMT
*  expire date: Jul  6 17:37:31 2038 GMT
*  subjectAltName: host "nifiregistry.our.network.com" matched cert's "nifiregistry.our.network.com"
*  issuer: DC=com; DC=network; DC=our; CN=AD1-CA
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /nifi-registry HTTP/1.1
> Host: nifiregistry.our.network.com:8443
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 01 Aug 2023 17:20:26 GMT
< Content-Security-Policy: frame-ancestors 'self'
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31540000
< Location: https://nifiregistry.our.network.com:8443/nifi-registry
< Content-Length: 0
<
* Connection #0 to host nifiregistry.our.network.com left intact

Nifi Properties

# web properties #
nifi.registry.web.war.directory=./lib
nifi.registry.web.http.host=
nifi.registry.web.http.port=
nifi.registry.web.https.host=123.4.56.78
nifi.registry.web.https.port=8443
nifi.registry.web.https.application.protocols=http/1.1
nifi.registry.web.jetty.working.directory=./work/jetty
nifi.registry.web.jetty.threads=200
nifi.registry.web.should.send.server.version=true

# security properties #
nifi.registry.security.keystore=./conf/keystore.p12
nifi.registry.security.keystoreType=PKCS12
nifi.registry.security.keystorePasswd=Password
nifi.registry.security.keyPasswd=Password
nifi.registry.security.truststore=./conf/truststore.p12
nifi.registry.security.truststoreType=PKCS12
nifi.registry.security.truststorePasswd=Password
nifi.registry.security.needClientAuth=
nifi.registry.security.authorizers.configuration.file=./conf/authorizers.xml
nifi.registry.security.authorizer=managed-authorizer
nifi.registry.security.identity.providers.configuration.file=./conf/identity-providers.xml
nifi.registry.security.identity.provider=ldap-identity-provider

 

mslnrd
mslnrdAnswer
Gold ⭐️
August 23, 2023

@MattWho 

I was able to get this resolved. It didn't require adding any other certificates other than my CA server certificate to the truststore for each server.  They share the same CA and so I used the same certificate in each truststore.

 

First, I am not sure why, but, NiFi did not like using port 636 for LDAPS, so I set it up to use 3269 instead and the SAN error went away.  Everything I tried prior did not resolve the error, it would give me an error that it couldn't find a SAN with my.network.com:636 along with partial LDAP result not being able to find my.network.com, which didn't make sense because all of the troubleshooting I did would come back good.  I could even resolve SSL using my key entry from my truststore.

 

Once I had it up and working after that, I had to figure out why the buckets weren't loading.  So I combed through a bunch of posts and found one that you wrote to someone having a similar issue and mentions the node needs to exist in NiFi-Registry. So, I added the node as "CN=node.hostname.com" (how I have it on the certificate) as a user account in NiFi Registry with the ability to read buckets and proxy user requests and bam buckets showed up.

 

Seems like everything is working great now.  I appreciate your help.

View in thread

12 replies

DianaTorres
Community Manager
DianaTorres
Community Manager
August 2, 2023

@mslnrd Welcome to the Cloudera Community!

To help you get the best possible solution, I have tagged our NiFi expert @steven-matison  who may be able to assist you further.

Please keep us updated on your post, and we hope you find a satisfactory solution to your query.

Translate
Regards, Diana Torres, Senior Community Moderator
mslnrd
mslnrdAuthor
Gold ⭐️
August 2, 2023

Hi,

 

Thanks for your response. I believe I may have figured out what the issue was.

I added false to 

nifi.registry.security.needClientAuth=

since we are not using client authentication for users or systems.  

Translate
MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
August 2, 2023

@mslnrd 
The NiFi Registry configuration property:

nifi.registry.security.needClientAuth=

is used to control whether NiFi-registry whether the TLS exchange is mutual (2-way TLS handshake if set to true) or 1-way TLS handshake (when set to false).

At a very high level, in a mutual TLS handshake both the server and the client need to provide their certificate in the the TLS handshakes.  When you changed this to false, NiFi-Registry no longer "required" that a client certificate is presented to identify the client who connected to the NiFi-Registry. If no other method of authentication is enabled, NiFi-Registry will treat the client as "anonymous".   NiFi-Registry supports anonymous user access to the NiFi-Registry UI.  This access is limited to accessing already created "public" buckets and ability to read flows version controlled in to a "public" bucket.

The ability to create buckets, administer buckets and flows, and write version controlled flows to any bucket would require an authenticated and authorized user.  

So it is not clear how this simple change solved your issue.  I think this change simple allowed the anonymous access only.

You'll need to inspect the keystore and truststore used by both NiFi (registry client ssl context) and NiFi-Registry (configured in nifi-registry.properties file) to make sure a mutual TLS exchange is possible.

 

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt

Translate
mslnrd
mslnrdAuthorAnswer
Gold ⭐️
August 23, 2023

@MattWho 

I was able to get this resolved. It didn't require adding any other certificates other than my CA server certificate to the truststore for each server.  They share the same CA and so I used the same certificate in each truststore.

 

First, I am not sure why, but, NiFi did not like using port 636 for LDAPS, so I set it up to use 3269 instead and the SAN error went away.  Everything I tried prior did not resolve the error, it would give me an error that it couldn't find a SAN with my.network.com:636 along with partial LDAP result not being able to find my.network.com, which didn't make sense because all of the troubleshooting I did would come back good.  I could even resolve SSL using my key entry from my truststore.

 

Once I had it up and working after that, I had to figure out why the buckets weren't loading.  So I combed through a bunch of posts and found one that you wrote to someone having a similar issue and mentions the node needs to exist in NiFi-Registry. So, I added the node as "CN=node.hostname.com" (how I have it on the certificate) as a user account in NiFi Registry with the ability to read buckets and proxy user requests and bam buckets showed up.

 

Seems like everything is working great now.  I appreciate your help.

Translate
DianaTorres
Community Manager
DianaTorres
Community Manager
August 7, 2023

@mslnrd Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.  Thanks.

Translate
Regards, Diana Torres, Senior Community Moderator
Terms & ConditionsAccessibility statement