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
MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
August 10, 2023

@mslnrd 
Don't confuse authentication with authorization.  
The only PrivateKeyEntry that can be in the NiFi-Registry keystore is the private key for the NiFi-Registry host on which NiFi-Registry is installed.
The only PrivateKeyEntry that can be in the NiFi keystore is the private key for the NiFi host on which NiFi- is installed.

These PrivateKeyEntries need to have EKUs for both clientAuth and ServerAuth. 

 

The truststore can have 1 too many TrustedCertEntries. Typically you would maintain singled truststore you use everywhere that contains all the intermediate and root Certificate Authorities (CAs) used to sign/issue the privateKey.  A truststore would not contain any PrivateKeyEntries.  It is intended for only public certs.

When NiFi initiates a connection to the configured NiFi-Registry client, a TLS handshake occurs, within that handshake the NIFi-registry (server side of handshake) will want NiFi to identify itself via a certificate that NiFi-Registry is capable of trusting.  The DistinguishedName (DN) of that clientAuth NiFi certificate is then used as the authenticated user identity. Also included in that exchange is the user identity for the user who is authenticated in NiFi initiating this client connection (via action of starting version control, stopping version control, initiating a version change, etc).

At that point authentication is done and authorization must then happen.  NiFi-Registry will check to see that the NiFi clientAuth DN is authorized to proxy the NIFi user's request and verify that the NiFi user identity is authorized to read and/or write to the bucket(s) in NiFi-registry.  These authorizations are setup from within the NiFi-registry UI.

The NiFi-Registry Admin guide covers the NiFi-Registry Access Policies and what those policies allow the authenticated user to do.

The NiFi-Registry User Guide covers how to manage users via the NiFi-Registry UI.

Since NiFi-Registry (just like NiFi) has identity mapping properties in the nifi-registry.properties configuration file to manipulate the user identity strings post successful authentication, the full DN may not be passed to the configured authorizer that handles the authorization phase.  It is common to have mapping s setup to trim only the CN out of the full DN of a certificate. Keep in mind that the user identity string passed to the authorizer is case sensitive and must match exactly.    The nifi-registry-app.log should be logging requests made by an authenticated user.  If you are seeing "anonymous" user in that log, then authentication was nit successful.  NiFi-Registry allows "anonymous" users to read from public buckets only.  

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