Error connecting to NiFi Registry from NiFi UI (certificate issue)

[#1]

I have multiple instances of nifi running and a central nifi registry is deployed. NiFi Registry is signed by an independent self-issued CA-signed certificate.

I do have a copy of NiFi Registry's truststore and keystore inside my NiFi instance (Kubernetes Pod). And I have configured the registry client with my registry's internal k8s service URL and the associated SSL Context is referenced to the Registry's truststore and keystores. The SSL Context Controller enables fine (indicating the keystores are accessible and the passwords are correct) but then I get the following error message while trying to enable versioning on a process group:

Unable to obtain listing of buckets: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I checked the other topics on this forum and on other forums on the Internet and found that this could be an issue with the validity of the registry's server certificate. The registry's server certificate is not being trusted by NiFi because it's unable to find matches in the referenced truststore.

I have tried verifying this manually from within the instance. I copied the registry's CA PEM certificate (the same one used while generating the registry's truststore and keystore)into the NiFi instance and verified the upstream registry server's certificate with the CA. I can confirm the server is accessible and the server certificates are valid. The truststore shouldn't be an issue and NiFi should be able to interact with the registry.

nifi@nifikop-0-node:/opt/nifi/nifi-current$ openssl s_client -connect nifi-registry.dev.svc.cluster.local:18443 -showcerts -CAfile /tmp/ca-cert.pem

CONNECTED(00000003)
depth=1 CN = 3SCDemo-CA, OU = 3SCDemo
verify return:1
depth=0 CN = nifi-registry, OU = 3SCDemo
verify return:1
---
Certificate chain
 0 s:CN = nifi-registry, OU = 3SCDemo
   i:CN = 3SCDemo-CA, OU = 3SCDemo
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 13 18:35:02 2025 GMT; NotAfter: Sep 13 18:35:02 2026 GMT
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
---
Server certificate
subject=CN = nifi-registry, OU = 3SCDemo
issuer=CN = 3SCDemo-CA, OU = 3SCDemo
---
Acceptable client certificate CA names
CN = 3SCDemo-CA, OU = 3SCDemo
CN = nifi-registry, OU = 3SCDemo
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+S
HA512
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RS
A-PSS+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1432 bytes and written 451 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: C84E2BFD44167DA371468E366F7E62CE8A2457A88A5FABADCEBA5A182CB29A28
    Session-ID-ctx:
    Resumption PSK: 57C3C840AF40C97DCA5E3C86C67ECC5943711E6D1CFD439DDDCDD30F8A599A620D89F0591288E0F7102C5031C266EFBC
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    ..ticket...

    Start Time: 1760469262
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

 
Ideally, I understand it should've worked. But I'm not sure where the issue lies..

[#2]

Hello @pnac03, 

Have you checked if the truststore has the CA cert from the NiFi Registry imported? 

keytool -list -keystore /path/to/truststore.jks

If is not listed there,  you will need to import it : 

keytool -importcert -alias 3SCDemo-CA -file /tmp/ca-cert.pem -keystore /path/to/truststore.jks

[#3]

Thank you for the quick reply @vafs !
As I have mentioned above, the truststore that I've referenced belongs to the NiFi Registry. I had copied the truststore from my NiFi Registry instance into my NiFi instance to eliminate any certificate mismatches. But yet it didn't work.

I however tried reimporting the ca certificate into the truststore as you suggested, but I still encounter the same issue while trying to version my flows

nifi@nifikop-0-node:/opt/nifi/nifi-current$ keytool -importcert -alias 3SCDemo-CA -file /tmp/ca-cert.pem -keystore /tmp/nifi-registry-truststore.jks
Enter keystore password:
Certificate already exists in keystore under alias <ca-cert>
Do you still want to add it? [no]: yes
Certificate was added to keystore
nifi@nifikop-0-node:/opt/nifi/nifi-current$  

[#4]

@pnac03 

A MutualTLS connection is established between NiFi and NiFi-Registry.  This means trust is established in both directions.

You shared only the output from an openssl command connection to your NiFi-Registry.
In that output we see that you NiFi-Registry reports the following:

Acceptable client certificate CA names
CN = 3SCDemo-CA, OU = 3SCDemo
CN = nifi-registry, OU = 3SCDemo

This tells us that your NiFi-Registry will only accept clientAuth certificates signed by the authorities listed in above output.

Also from that same openssl command output we can see the following details of your NiFi-Registry's serverAuth certificate:

Certificate chain
 0 s:CN = nifi-registry, OU = 3SCDemo
   i:CN = 3SCDemo-CA, OU = 3SCDemo
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 13 18:35:02 2025 GMT; NotAfter: Sep 13 18:35:02 2026 GMT

Here we can see that your NiFi-Registry certificate has been signed/Issued by the CA "CN=3SCDemo-CA, OU=3SCDemo".

What you have not shared yet is details from the other side of this mutualTLS connection.

If you ran the same openssl command pointing at your NiFi node it would show us some of the TLS connection details.  You would want to look at the same NiFi's certificate chain and the NiFi's acceptable client certificate CA Names form that output.  The CA names list must include the following to be able to trust the NiFi-Registry's serverAuth certificate:

CN = 3SCDemo-CA, OU = 3SCDemo

Then you want to look at the NiFi's certificate chain and make sure that all root and intermediate CAs in the trust chain exist in your NiFi-Registry's truststore.   Currently your NiFi-Registry only trusts its own certificate and the one above CA.   

Also keep in mind the following:

• If you have a NiFi cluster setup, every node in the Nifi cluster must be able to establish a mutualTLS connection with your NiFi-Registry and not just the node URL you are currently connected to for UI access.
• If you do not have the following setting set to "TRUE" in the nifi.properties file, any changes made to the keystore and truststore are not loaded into NiFi until a NiFi restart:  "nifi.security.autoreload.enabled".  the default setting is FALSE. 
  Reference: Security Configuration

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

[#5]

@MattWho Thank you for the response. 

I'm on a single node nifi setup. As you suggested, I tried verifying my certificates the other way round i.e. NiFi Node's server certificates from my NiFi Registry. As expected, it didn't verify succesfully. As I had previously mentioned, my NiFi Nodes are being signed by cert manager and I'm using a self signed central nifi registry to connect from different single-node NiFi Clusters. I have attached an illustration of my setup below.

Since my NiFi Nodes are connecting from different environments and the fact that I use different cert-manager deployments to sign the certs for the respective Nodes, how can i connect to the registry without having to update the registry's truststore everytime I need to spin up a new nifi cluster in a new environment.

If I understand this correctly, the SSL context management controller is supposed to exactly solve this kind of problem right? The SSL Context in my NiFi Node(s) should contain the paths to the keystore and the truststore of my NiFi Registry, on the NiFi Node's local filesystem, isn't it? If I had multiple registries to connect to, I could simply similarly configure additional SSL Contexts for the respective registries in NiFi's management controller services isn't it? Please correct me if I'm wrong..

[#6]

@pnac03 

You are correct, The NiFiRegistry client should be using the keystore and truststore configured in the configured SSLContextService in the MutualTLS handshake with the target NiFi-Registry.

Can you share the verbose keytool output for both your NiFi-Registry keystore and truststore?

Verify that the keystore contains:

• Only one "PrivateKeyEntry"
• The PrivateKeyEntry "Owner" and "Issuer".  If not same DN, then it is not self-signed.
• The PrivateKeyEntry "ExtendedKeyUsages" (EKU).  Since you are trying to use this to perform "client" side connection to your NiFi-Registry from NiFi, it must include "clientAuth" as one of the EKUs
• Verify PrivateKeyEntry "KeyUsage"

Verify that the truststore contians:

• One or more "trustedCertEntry"s.   It should include the complete trustchain.

From the original openssl s_client connect command output you shared, I see you have a server certificate that has been signed by a Certificate Authority (CA).  The truststore used in the NiFi-Registry client in NiFi must contain the CA certificate.

Using below openssl command will output every public certificate.  You can then copy each and import them in to the truststore you configured your NiFis to use in the NiFi-Registry client SSLContext.   

openssl_s_client -connect <nifi-registry hostname>:<nifi-registry port> --showcerts

 Here is the keytool command to verify the keystore information:

keytool -v -list -keystore <keystore or truststore file>

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

[#7]

Please find my verbose keytool output for both my keystore and truststore of my NiFi Registry. The same keystore and truststores were copied over to my NiFi instances (via 'kubectl cp' utilities) and have been referenced via SSL Context

nifi@nifi-registry-0:/opt/certs$ keytool -v -list -keystore nifi-registry-keystore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: nifi-registry
Creation date: Sep 13, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: OU=3SCDemo, CN=nifi-registry
Issuer: OU=3SCDemo, CN=3SCDemo-CA
Serial number: 4c6bdbce9df169456145d320bd438808765291b
Valid from: Sat Sep 13 18:35:02 UTC 2025 until: Sun Sep 13 18:35:02 UTC 2026
Certificate fingerprints:
<fingerprints>
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 1


*******************************************
*******************************************


nifi@nifi-registry-0:/opt/certs$ keytool -v -list -keystore nifi-registry-truststore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: ca-cert
Creation date: Oct 29, 2025
Entry type: trustedCertEntry

Owner: OU=3SCDemo, CN=3SCDemo-CA
Issuer: OU=3SCDemo, CN=3SCDemo-CA
Serial number: 429a23e0a595c4721f6f7f0933e69ebcca616027
Valid from: Sat Sep 13 18:35:02 UTC 2025 until: Sun Sep 13 18:35:02 UTC 2026
Certificate fingerprints:
<fingerprints>
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [ .. ]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen: no limit
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [ .. ]




*******************************************
*******************************************


Alias name: nifi-registry
Creation date: Oct 29, 2025
Entry type: trustedCertEntry

Owner: OU=3SCDemo, CN=nifi-registry
Issuer: OU=3SCDemo, CN=3SCDemo-CA
Serial number: 4c6bdbce9df169456145d320bd438808765291b
Valid from: Sat Sep 13 18:35:02 UTC 2025 until: Sun Sep 13 18:35:02 UTC 2026
Certificate fingerprints:
<fingerprints>
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 1


*******************************************
*******************************************

In essence, NiFi Registry is essentially not recognizing certificates being presented from its own keystores and truststores via NiFi's SSL Context services

[#8]

@pnac03 

Looks like you truncated the output of the keytool command for your keystore.
What are the "ExtendedKeyUsages" (EKU) on your PrivateKeyEntry?

It must have:

ExtendedKeyUsages [
  serverAuth
  clientAuth
]

If it is missing "clientAuth", it can't be used in NiFi by the NiFRegistryFlowRegistryClient because it won't present a client certificate in the mutualTLS exchange. 

But even above if no clientAuth EKU would not explain the exception you get:

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This exception is caused by a trust issue. 
The copied over keystore and truststore are owned by the NiFi service user and the NiFi service user can traverse the directory path the the keystore and truststore? 
The URL used in the NiFiRegistryFlowRegistryClient is using https and not http?

Thanks,
Matt

[#9]

yes. I am using 'https' to reach the registry.
I found out my registry's certificates really don't have the ExtendedKeyUsage Extensions. I will try recreating new certificates with the extensions and will get back. 

Also, since I'm using LDAP to secure my Registry, I had set clientAuth to false. Will that not interfere while NiFi is trying to connect to the registry since we are using mTLS in this case and not LDAP credentials for authentication? So, is it mandatory that I configure a composite user group (filebased and LDAP) in my registry's authorizers for authentication?

[#10]

@pnac03 

When "nifi.registry.security.needClientAuth" is set to "true", NiFi-Registry will "Require" a clientAuth certificate be presented in every mutualTLS exchange with the NiFi https endpoint.    When set to "false", NiFi-Registry will "Want"' a clientAuth certificate to be provided in every  mutualTLS exchange.  When you access NiFi-Registry's URL you'll notice that your browser does not present a ClientAuth certificate so NIFi-Registry shows anonymous access.   You then must click login to provide your ldap credentials to authenticate as your user for which you have setup authorization for.  All connections between NiFi and NiFi-Registry must present a clientAuth certificate in response to the Want since no other auth method is supported in that connection pathway.  

Securing your NiFi or NiFi-Registry requires providing proper tls certificate keystore and truststore.  Setting up LDAP as an alternative method of authentication is not a requirement; however, it is the most commonly method used.  You could just create a clientAuth certificate (must be signed by a trusted authority in the truststore) for every user that can be loaded into their browser to authenticate access to NiFi and NiFi-Registry.  Authorization happens after successful authentication.  The user/client identity resulting from successful authentication is based to the configured authorizer to verify that client/user identity is authorized as needed for the request endpoint.  So authorizers is always going to be needed.  Which user-group-providers you choose to use in the authorizers.xml to define the client/user identities you will set authorization policies for is up to you.  The file-user-group-provider is needed to setup authorizations for your clientAuth certificate based identities.   Of course you can also use this provider to manually configure your user identities that match with your ldap (simple if you only have few users).  the ldap-user-group-provider is better if you want to do ldap group based authorizations or you want to authorize a lot of user identities.  Doing a based on ldap groups makes it easy to control access by adding or removing users from groups in ldap. 

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt