Skip to main content
pnac03
pnac03
Silver ⭐️⭐️⭐️
January 6, 2026
Solved

Authorization issue between NiFi and NiFi Registry

I am trying to connect between NiFi and NiFi Registry. I'm able to authenticate with Registry from NiFi but I'm unable to see the buckets, not even the public ones. I've configured a SSL Context on NiFi that references a truststore containing Registry's Truststore and Keystore. I've imported NiFi's node certificates into the truststore on the registry's side. I've given the 'proxy and manage user bucket' permissions to the Node's identity in the Registry UI and Read Write and Execute permission to the same user on the Buckets. But I'm still unable to see the buckets on NiFi's UI. The API Responses also indicate that NiFi only has read permissions to the buckets. This is as if there is some anomaly during login.. 

Note:
1) I'm using a Clustered NiFi Setup. I have verified that my node identity is 'CN=node-0-nifikop'.
2) Both NiFi Cluster (NiFiKop) and the NiFi Registry (Helm Release) are running inside a Kubernetes Cluster

Error Samples:

The Error on NiFi UI:  Error.jpeg
Registry Bucket Policies:  Bucket Policies.jpeg
Registry User Permissions:  Registry User Permissions.jpeg

The following is the Truststore referenced in NiFi's SSL Contexts

======================================
NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED
======================================

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 4 entries

Alias name: ca-cert
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: O=3SCDemo, CN=3SCDemo-CA
Issuer: O=3SCDemo, CN=3SCDemo-CA
Serial number: 1745e28f179548d468a6ece0d0d497be8b15d74f
Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026
Certificate fingerprints:
	 SHA1:  SHA256: 
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.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

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



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


Alias name: nifi-ca
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: CN=nifikop-ca.dev.cluster.local
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: 
Valid from: Mon Dec 29 07:08:21 UTC 2025 until: Sun Mar 29 07:08:21 UTC 2026
Certificate fingerprints:
	 SHA1:  SHA256: 
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

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

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
  Key_CertSign
]

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



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


Alias name: nifi-prod
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: CN=node-0-nifikop
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: 
Valid from: Mon Dec 29 07:08:26 UTC 2025 until: Sun Mar 29 07:08:26 UTC 2026
Certificate fingerprints:
	 SHA1:  SHA256: 
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions: 

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

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  clientAuth
  serverAuth
]

#4: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: nifikop-headless.dev.svc.cluster.local
  DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local
  DNSName: nifikop-headless.dev.svc
  DNSName: nifikop-0-node.nifikop-headless.dev.svc
  DNSName: nifikop-headless.dev
  DNSName: nifikop-0-node.nifikop-headless.dev
  DNSName: nifikop-headless
  DNSName: nifikop-0-node.nifikop-headless
  DNSName: nifikop-0-node
  DNSName: adinifiapp.com
  URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop
]



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


Alias name: nifi-reg-keystore-import
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: O=3SCDemo, CN=nifi-registry
Issuer: O=3SCDemo, CN=3SCDemo-CA
Serial number: 
Valid from: Sat Dec 20 19:51:52 UTC 2025 until: Sun Dec 20 19:51:52 UTC 2026
Certificate fingerprints:
	 SHA1: 	 SHA256: 
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=false
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]

#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]

#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: nifi-registry
  DNSName: nifi-registry.dev
  DNSName: nifi-registry.dev.svc
  DNSName: nifi-registry.dev.svc.cluster.local
  DNSName: localhost
  IPAddress: 127.0.0.1
]

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



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

======================================
NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED
======================================


The following is the truststore of NiFi Registry

======================================
NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED
======================================

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 3 entries

Alias name: ca-cert
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: O=3SCDemo, CN=3SCDemo-CA
Issuer: O=3SCDemo, CN=3SCDemo-CA
Serial number: 
Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026
Certificate fingerprints:
	 SHA1: 	 SHA256: 
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.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

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



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


Alias name: nifi-ca
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: CN=nifikop-ca.dev.cluster.local
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: 
Valid from: Mon Dec 29 07:08:21 UTC 2025 until: Sun Mar 29 07:08:21 UTC 2026
Certificate fingerprints:
	 SHA1: 	 SHA256: 
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

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

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
  Key_CertSign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EB 16 CA 18 17 7C 14 24   E3 FC 9D E7 EE CA A6 80  .......$........
0010: A1 63 D1 BB                                        .c..
]
]



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


Alias name: nifi-prod
Creation date: Jan 5, 2026
Entry type: trustedCertEntry

Owner: CN=node-0-nifikop
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: 
Valid from: Mon Dec 29 07:08:26 UTC 2025 until: Sun Mar 29 07:08:26 UTC 2026
Certificate fingerprints:
	 SHA1: 	 SHA256:
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions: 

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

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  clientAuth
  serverAuth
]

#4: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: nifikop-headless.dev.svc.cluster.local
  DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local
  DNSName: nifikop-headless.dev.svc
  DNSName: nifikop-0-node.nifikop-headless.dev.svc
  DNSName: nifikop-headless.dev
  DNSName: nifikop-0-node.nifikop-headless.dev
  DNSName: nifikop-headless
  DNSName: nifikop-0-node.nifikop-headless
  DNSName: nifikop-0-node
  DNSName: adinifiapp.com
  URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop
]

*******************************************
*******************************************
======================================
NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED
======================================


This is the kind of response i get when I hit this API:
https://domain-name/context-path/nifi-api/flow/registries/9e779b09-0199-1000-ffff-ffffec7d027b/buckets

{
    "buckets": [
        {
            "id": "38257128-3406-4fe7-9a7e-967340552ca8",
            "bucket": {
                "id": "38257128-3406-4fe7-9a7e-967340552ca8",
                "name": "fddf",
                "description": "",
                "created": 1760507389992
            },
            "permissions": {
                "canRead": true,
                "canWrite": false
            }
        }
    ]
}

Another Clarification: 
If I understand this right, in case of a clustered setup, the certificate referenced in the SSL Context is proxied via the Node's Identity while NiFi presents its own identity to Registry during the mTLS Handshake. So what registry would see in case of a clustered nifi setup would be the node's identity instead of that Certificate which is referenced in NiFi's SSL Contexts. I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context.
 

MattWho
MattWhoAnswer
Titanium ⭐️⭐️⭐️
January 20, 2026

@pnac03 

Based on your nifi-registry.properties file, there is no user identity manipulation happening.  This means that the full DistinquishedName (DN) presented by NiFi in the MutualTLS exchange with NiFi-Registry will be the user identity for the registry client connecting to your NiFi-Registry.  That means that the full DN needs to be authorized in NiFi-Registry properly.  That DN needs to be authorized for the following Special Privileges:

"Can manage buckets" - Read
"Can proxy user requests" - Read, Write, and Delete

From the keystore you shared fro your SSL Context Service, we can see it properly contains only one PrivateKeyEntry and the DN for that clientAuth privateKey is:

O=3SCDemo, CN=nifi-registry

So the above (case sensitive) MUST exist as a user in your NiFi-Registry and have granted to it the above special Privileges mentioned.

Also, the user identity of the user logged into NiFi (as displayed in upper right corner - case sensitive) when attempting start version control on a process group in NiFi will need to exist as a user in your NiFi-Registry and be authorized properly directly on the bucket in which you want to version control the process group (this is different then the Special Privileges section in NiFi-Registry). 

Read Bucket - Allows user to see version controlled flows in the bucket.
Write Bucket - Allows user to commit new version controlled flows to the bucket
Delete Bucket - allows user to delete a bucket.

 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

View in thread

7 replies

MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
January 6, 2026

@pnac03 

Some clarification:

The NiFi Registry Client (NifiRegistryFlowRegistryClient) will use the configured keystore and truststore in the defined SLS ContextService if configured to authenticate with the target NiFi Registry URL.  This Client Auth certificate will proxy the request on behalf of the user identity displayed in the upper right corner of the NiFi UI where this NiFi Registry client is being used.   If an SSL Context Service is not defined in the Registry client, the Registry client will use the keystore and truststore configured in the NiFi node's nifi.properties files.  Now it is common in a Nifi cluster setup that every node has its own unique keystore.  As such you would need to make sure that all the clientAuth certificates are properly authorized to proxy user requests in the target NiFi (this applies no matter which NiFi node you are logged into when making the call to NiFi-Registry since the request gets replicated by all nodes.). 

That brings into question your statement below:

I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context.

Can you share the verbose output for your PrivateKeyEntry?  Does it contain only 1 PrivateKey Entry or multiple?  (Must contain only one since NiFi Registry client does not provide a configuration option to specify a specific certificate by alias name.

-----
Public bucket clarification:

A public bucket allows any user to import a flow from that bucket to the Canvas of a NiFi.  It does not allow any user to write (start version control) of a new dataflow or commit new version of an existing version controlled dataflow to the public bucket.  Writing a new flow to a bucket will require proper write permission on the bucket regardless of whether the bucket is public or not.

-------
User Identities:
 The user identities coming from the ssl context services and proxied are case sensitive "User 2" and "user 2" would be treated as to different users in both NiFi and NiFi-Registry.

The User identities are evaluated against any identity mappings that may be configured in the nifi-registry.properties file, so you'll want to take a look at these to make sure they are not manipulating the user identity string or clientAuth certificate DN.



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

 

Translate
    pnac03
    pnac03Author
    Silver ⭐️⭐️⭐️
    January 6, 2026

    @MattWho  Thanks for the quick reply! Thanks for the clarification on the proxying.
    I checked my setup and I have these three questions:

    1) Do you need the verbose output from the tcpdump utility or from my NiFi Node's keystore ?
    I've shared the verbose output of my NiFi Node's keystore below. It does seem that my keystore has 2 aliases (or PrivateKeyEntries) indeed, one of them carrying the certificate involved i.e. CN=node-0-nifikop

    nifi@nifikop-0-node:/var/run/secrets/java.io/keystores/server$ keytool --list -v --keystore keystore.jks
    Enter keystore password:
    Keystore type: JKS
    Keystore provider: SUN

    Your keystore contains 2 entries

    Alias name: ca
    Creation date: Nov 24, 2025
    Entry type: trustedCertEntry

    Owner: CN=nifikop-ca.dev.cluster.local
    Issuer: CN=nifikop-ca.dev.cluster.local
    Serial number: f6b7c60ecee584faa4b5778b6667a7fb
    Valid from: Mon Oct 13 21:43:39 UTC 2025 until: Sun Jan 11 21:43:39 UTC 2026
    Certificate fingerprints:
    SHA1: 56:05:68:C3:15:7F:82:A0:C8:90:6D:DF:BE:02:3E:10:7F:9D:C0:05
    SHA256: 32:46:2C:84:04:D0:91:D9:A8:05:D3:8B:07:E2:09:1C:E3:AC:75:17:77:CB:86:EA:BE:90:9E:09:6F:77:4B:3A
    Signature algorithm name: SHA256withRSA
    Subject Public Key Algorithm: 2048-bit RSA key
    Version: 3

    Extensions:

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

    #2: ObjectId: 2.5.29.15 Criticality=true
    KeyUsage [
    DigitalSignature
    Key_Encipherment
    Key_CertSign
    ]

    #3: ObjectId: 2.5.29.14 Criticality=false
    SubjectKeyIdentifier [
    KeyIdentifier [
    0000: 0C A4 00 26 2F 44 ED FF BD 2C 3F 76 8F 6C FA CB ...&/D...,?v.l..
    0010: 2A 48 0E A2 *H..
    ]
    ]




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


    Alias name: certificate
    Creation date: Nov 24, 2025
    Entry type: PrivateKeyEntry
    Certificate chain length: 1
    Certificate[1]:
    Owner: CN=node-0-nifikop
    Issuer: CN=nifikop-ca.dev.cluster.local
    Serial number: b15ef24eef5835b02b5921d40726a453
    Valid from: Mon Nov 24 06:29:55 UTC 2025 until: Sun Feb 22 06:29:55 UTC 2026
    Certificate fingerprints:
    SHA1: 80:60:7E:27:D9:8A:3D:10:C0:47:0E:72:C1:31:17:D7:7C:3E:3E:AF
    SHA256: 07:25:53:5B:05:00:5F:16:E6:12:B9:44:77:D6:A6:7C:83:F8:80:F7:4A:DB:F3:F6:DF:32:F6:31:56:AC:66:FF
    Signature algorithm name: SHA256withRSA
    Subject Public Key Algorithm: 4096-bit RSA key
    Version: 3

    Extensions:

    #1: ObjectId: 2.5.29.35 Criticality=false
    AuthorityKeyIdentifier [
    KeyIdentifier [
    0000: 0C A4 00 26 2F 44 ED FF BD 2C 3F 76 8F 6C FA CB ...&/D...,?v.l..
    0010: 2A 48 0E A2 *H..
    ]
    ]

    #2: ObjectId: 2.5.29.19 Criticality=true
    BasicConstraints:[
    CA:false
    PathLen: undefined
    ]

    #3: ObjectId: 2.5.29.37 Criticality=false
    ExtendedKeyUsages [
    clientAuth
    serverAuth
    ]

    #4: ObjectId: 2.5.29.17 Criticality=false
    SubjectAlternativeName [
    DNSName: nifikop-headless.dev.svc.cluster.local
    DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local
    DNSName: nifikop-headless.dev.svc
    DNSName: nifikop-0-node.nifikop-headless.dev.svc
    DNSName: nifikop-headless.dev
    DNSName: nifikop-0-node.nifikop-headless.dev
    DNSName: nifikop-headless
    DNSName: nifikop-0-node.nifikop-headless
    DNSName: nifikop-0-node
    DNSName: nifi-internal.3sc.com
    URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop
    ]




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




    Warning:
    The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".

    Note: My NiFi Cluster also has an Operator and this is all deployed inside a Kubernetes Cluster. Cert-manager is used to generate and manage these certificates.

    2) Does the TLS Version matter in the SSL Context? Currently it's set to 'TLS' and I tried even with SSL and it hadn't worked.

    3) Although I've referenced another working certificate (with clientAuth EKUs) in the SSL Context which has "O=3SCDemo, CN=nifi-registry" as the Subject Name and exactly one alias in that keystore, why is NiFi is still presenting the node's certificate referenced in nifi.properties to the registry (as I had confirmed using tcpdump). I didn't see any other CN Name except CN=node-0-nifikop). 

    Translate
    MattWho
    Titanium ⭐️⭐️⭐️
    MattWho
    Titanium ⭐️⭐️⭐️
    January 7, 2026

    @pnac03 

    1). The keystore configured in NiFi (nifi.properies and in SSL Context Service controller services) and NiFi-Registry (nifi-registry.properties) must contain only 1 PrivateKeyEntry since there is no way to control which is used when multiple exist.  The verbose output you shared for your keystore shows it containing only 1 PrivateKeyEntry.

    2) TLS will negotiate the highest mutually supported version between client and server in the mTLS exchange.

    3) You did not share the verbose output for the keystore used in the SSL Context Service you configured your NiFiFlowRegistry client to use.  Would also need to see the nifi-registry.properties file to inspect all the identity mapping properties set to see how the DNs might be manipulated.

    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

    Translate
      pnac03
      pnac03Author
      Silver ⭐️⭐️⭐️
      January 8, 2026

      @MattWho Thanks for the clarifications.

      Here's the verbose output of the keystore used in the SSL Context Service for my NiFiFlowRegistryClient

       

      Keystore type: JKS
      Keystore provider: SUN

      Your keystore contains 1 entry

      Alias name: nifi-registry
      Creation date: Dec 20, 2025
      Entry type: PrivateKeyEntry
      Certificate chain length: 2

      Certificate[1]:

      Owner: O=3SCDemo, CN=nifi-registry
      Issuer: O=3SCDemo, CN=3SCDemo-CA
      Serial number: 
      Valid from: Sat Dec 20 19:51:52 UTC 2025 until: Sun Dec 20 19:51:52 UTC 2026
      Certificate fingerprints:
      SHA1: SHA256: 
      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=false
      BasicConstraints:[
        CA:false
        PathLen: undefined
      ]
      #3: ObjectId: 2.5.29.37 Criticality=false
      ExtendedKeyUsages [
        serverAuth
        clientAuth
      ]
      #4: ObjectId: 2.5.29.15 Criticality=true
      KeyUsage [
        DigitalSignature
        Key_Encipherment
      ]
      #5: ObjectId: 2.5.29.17 Criticality=false
      SubjectAlternativeName [
        DNSName: nifi-registry
        DNSName: nifi-registry.dev
        DNSName: nifi-registry.dev.svc
        DNSName: nifi-registry.dev.svc.cluster.local
        DNSName: localhost
        IPAddress: 127.0.0.1
      ]
      #6: ObjectId: 2.5.29.14 Criticality=false
      SubjectKeyIdentifier [
      KeyIdentifier [
                                             ....
      ]
      ]

      Certificate[2]:

      Owner: O=3SCDemo, CN=3SCDemo-CA
      Issuer: O=3SCDemo, CN=3SCDemo-CA
      Serial number: 
      Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026
      Certificate fingerprints:
      SHA1: SHA256: 
      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.15 Criticality=true
      KeyUsage [
        DigitalSignature
        Key_CertSign
        Crl_Sign
      ]
      #4: ObjectId: 2.5.29.14 Criticality=false
      SubjectKeyIdentifier [
      KeyIdentifier [
                                          +...
      ]
      ]

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


      Please find the nifi-registry.properties file:

      # web properties #
      nifi.registry.web.war.directory=./lib
      nifi.registry.web.http.host=
      nifi.registry.web.http.port=
      nifi.registry.web.https.host=nifi-registry-0
      nifi.registry.web.https.port=18443
      nifi.registry.web.https.network.interface.default=
      nifi.registry.web.https.application.protocols=h2 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=/opt/certs/nifi-registry-keystore.jks
      nifi.registry.security.keystoreType=JKS
      nifi.registry.security.keystorePasswd=newps
      nifi.registry.security.keyPasswd=newps
      nifi.registry.security.truststore=/opt/certs/nifi-registry-truststore.jks

      nifi.registry.security.truststoreType=JKS
      nifi.registry.security.truststorePasswd=newps
      nifi.registry.security.needClientAuth=false
      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

      # providers properties #
      nifi.registry.providers.configuration.file=./conf/providers.xml

      # registry alias properties #
      nifi.registry.registry.alias.configuration.file=./conf/registry-aliases.xml

      # extensions working dir #
      nifi.registry.extensions.working.directory=./work/extensions

      # legacy database properties, used to migrate data from original DB to new DB below
      # NOTE: Users upgrading from 0.1.0 should leave these populated, but new installs after 0.1.0 should leave these empty
      nifi.registry.db.directory=
      nifi.registry.db.url.append=

      # database properties
      nifi.registry.db.url=jdbc:h2:./database/nifi-registry-primary;AUTOCOMMIT=OFF;DB_CLOSE_ON_EXIT=FALSE;LOCK_MODE=3;LOCK_TIMEOUT=25000;WRITE_DELAY=0;AUTO_SERVER=FALSE
      nifi.registry.db.driver.class=org.h2.Driver
      nifi.registry.db.driver.directory=
      nifi.registry.db.username=nifireg
      nifi.registry.db.password=nifireg
      nifi.registry.db.maxConnections=5
      nifi.registry.db.sql.debug=false

      # extension directories #
      # Each property beginning with "nifi.registry.extension.dir." will be treated as location for an extension,
      # and a class loader will be created for each location, with the system class loader as the parent
      #
      #nifi.registry.extension.dir.1=/path/to/extension1
      #nifi.registry.extension.dir.2=/path/to/extension2
      nifi.registry.extension.dir.aws=./ext/aws/lib

      # Identity Mapping Properties #
      # These properties allow normalizing user identities such that identities coming from different identity providers
      # (certificates, LDAP, Kerberos) can be treated the same internally in NiFi. The following example demonstrates normalizing
      # DNs from certificates and principals from Kerberos into a common identity string:

      #
      # nifi.registry.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$
      # nifi.registry.security.identity.mapping.value.dn=$1@$2
      # nifi.registry.security.identity.mapping.transform.dn=NONE
      # nifi.registry.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
      # nifi.registry.security.identity.mapping.value.kerb=$1@$2
      # nifi.registry.security.identity.mapping.transform.kerb=UPPER

      # Group Mapping Properties #
      # These properties allow normalizing group names coming from external sources like LDAP. The following example
      # lowercases any group name.
      #
      # nifi.registry.security.group.mapping.pattern.anygroup=^(.*)$
      # nifi.registry.security.group.mapping.value.anygroup=$1
      # nifi.registry.security.group.mapping.transform.anygroup=LOWER

      # kerberos properties #
      nifi.registry.kerberos.krb5.file=
      nifi.registry.kerberos.spnego.principal=
      nifi.registry.kerberos.spnego.keytab.location=
      nifi.registry.kerberos.spnego.authentication.expiration=12 hours

      # OIDC #

      nifi.registry.security.user.oidc.discovery.url=
      nifi.registry.security.user.oidc.connect.timeout=
      nifi.registry.security.user.oidc.read.timeout=
      nifi.registry.security.user.oidc.client.id=
      nifi.registry.security.user.oidc.client.secret=
      nifi.registry.security.user.oidc.preferred.jwsalgorithm=
      nifi.registry.security.user.oidc.additional.scopes=${nifi.registry.security.user.oidc.additional.scopes}
      nifi.registry.security.user.oidc.claim.identifying.user=${nifi.registry.security.user.oidc.claim.identifying.user}
      nifi.registry.security.user.oidc.claim.groups=groups

      # revision management #
      # This feature should remain disabled until a future NiFi release that supports the revision API changes
      nifi.registry.revisions.enabled=false

      Translate
      pnac03
      pnac03Author
      Silver ⭐️⭐️⭐️
      January 20, 2026

      @MattWho Were you able to check the outputs from my last reply? Tried other methods, still no luck..

      Translate
      MattWho
      Titanium ⭐️⭐️⭐️
      MattWhoAnswer
      Titanium ⭐️⭐️⭐️
      January 20, 2026

      @pnac03 

      Based on your nifi-registry.properties file, there is no user identity manipulation happening.  This means that the full DistinquishedName (DN) presented by NiFi in the MutualTLS exchange with NiFi-Registry will be the user identity for the registry client connecting to your NiFi-Registry.  That means that the full DN needs to be authorized in NiFi-Registry properly.  That DN needs to be authorized for the following Special Privileges:

      "Can manage buckets" - Read
      "Can proxy user requests" - Read, Write, and Delete

      From the keystore you shared fro your SSL Context Service, we can see it properly contains only one PrivateKeyEntry and the DN for that clientAuth privateKey is:

      O=3SCDemo, CN=nifi-registry

      So the above (case sensitive) MUST exist as a user in your NiFi-Registry and have granted to it the above special Privileges mentioned.

      Also, the user identity of the user logged into NiFi (as displayed in upper right corner - case sensitive) when attempting start version control on a process group in NiFi will need to exist as a user in your NiFi-Registry and be authorized properly directly on the bucket in which you want to version control the process group (this is different then the Special Privileges section in NiFi-Registry). 

      Read Bucket - Allows user to see version controlled flows in the bucket.
      Write Bucket - Allows user to commit new version controlled flows to the bucket
      Delete Bucket - allows user to delete a bucket.

       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

      Translate
        pnac03
        pnac03Author
        Silver ⭐️⭐️⭐️
        February 14, 2026

        Thanks @MattWho 

        Probably as a result of a nifikop-operator based, LDAP-Authenticated, Clustered Nifi setup, I had to give permissions to both the DN you mentioned and my nifi user (as visible on the top right corner of my nifi UI).

        Effective Permissions:
        - Can Proxy User Requests and Can Manage Buckets to both the Users
        - Read, Write and Delete (if required) access to my buckets

        Now I'm able to list and interact with my buckets from my nifi UI!

        Translate
        Terms & ConditionsAccessibility statement