nifi mutual tls version 1 vs version 2

[#1]

Good evening, I am having a lot of trouble getting an instance of NiFi running with Mutual TLS. I have different errors depending on whether the effort involves version 1.xx or version 2.xx. I'm hoping to get some help. This is all being attempted via Docker.

My YAML:
```

version: "3.9"

services:

  nifi:

    image: apache/nifi:1.24.0

    # hostname: nifi

    container_name: nifi

    ports:

      # - 8443:8443

      - "9449:9449"

    environment:

      - NIFI_WEB_HTTPS_PORT=9449

      - NIFI_WEB_HTTPS_HOST=0.0.0.0

      - NIFI_WEB_PROXY_HOST=localhost,localhost:9449,192.168.1.56,192.168.1.56:9449

      - AUTH=tls

      - KEYSTORE_PATH=/opt/nifi/nifi-current/certs/jks/nifi-ks.jks

      - KEYSTORE_TYPE=JKS

      - KEYSTORE_PASSWORD=randomPassword

      - TRUSTSTORE_PATH=/opt/nifi/nifi-current/certs/jks/truststore.jks

      - TRUSTSTORE_PASSWORD=randomPassword

      - TRUSTSTORE_TYPE=JKS

      - INITIAL_ADMIN_IDENTITY='CN=admin'

      - NIFI_SENSITIVE_PROPS_KEY=randomKey

    volumes:

      - nifi_flowfile_repo:/opt/nifi/nifi-current/flowfile_repository

      - nifi_content_repo:/opt/nifi/nifi-current/content_repository

      - nifi_provenance_repo:/opt/nifi/nifi-current/provenance_repository

      - nifi_conf:/opt/nifi/nifi-current/conf

      - nifi_db:/opt/nifi/nifi-current/database_repository

      - /opt/nifi-custom-setup/version_2-0-0/20240130/certs/ca-openssl:/opt/nifi/nifi-current/certs

      - /opt/nifi-custom-setup/version_2-0-0/add_nars:/opt/nifi/nifi-current/add_nars

      - /mnt/scripts:/opt/nifi/nifi-current/custom_scripts

      - /mnt/datashare_source_data2:/mnt/datashare_source_data2

      - /mnt/drivers/postgresql-42.6.0.jar:/opt/nifi/nifi-current/lib/postgresql-42.6.0.jar

      - /usr/local/bin:/usr/local/bin:ro

      - /usr/local/lib:/usr/local/lib:ro

    # entrypoint: ["/bin/bash", "/opt/nifi/nifi-current/custom_scripts/custom_entrypoint.sh"]

    restart: unless-stopped

volumes:

  nifi_flowfile_repo:

  nifi_content_repo:

  nifi_provenance_repo:

  nifi_conf:

  nifi_db:
```

relevant initial logs when the container boots up:
```
2024-01-31 00:20:34,016 INFO [main] org.eclipse.jetty.server.Server Started @31422ms
2024-01-31 00:20:34,031 INFO [main] org.apache.nifi.web.server.JettyServer NiFi has started. The UI is available at the following URLs:
2024-01-31 00:20:34,031 INFO [main] org.apache.nifi.web.server.JettyServer https://0.0.0.0:9449/nifi
```
Error from the web browser when I attempt to log in (It does successfully prompt me for my .p12 certificate and that seems to work.)

Insufficient Permissions

• home

Unable to view the user interface. Contact the system administrator.

Error from within the container related to the above:
```
ifi@8c3733a74f02:/opt/nifi/nifi-current/logs$ cat nifi-user.log
2024-01-31 00:20:41,209 INFO [NiFi Web Server-32] o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 192.168.1.1 [CN=admin] GET https://ddla.w.ccu:9449/nifi-api/flow/current-user
2024-01-31 00:20:41,209 INFO [NiFi Web Server-32] o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin] 192.168.1.1 GET https://ddla.w.ccu:9449/nifi-api/flow/current-user
2024-01-31 00:20:41,252 INFO [NiFi Web Server-32] o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=admin], groups[] does not have permission to access the requested resource. Unable to view the user interface. Returning Forbidden response.
nifi@8c3733a74f02:/opt/nifi/nifi-current/logs$
```
The relevant portion from the `authorizers.xml` file:

```
<!-- <authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Users File">./conf/users.xml</property>
<property name="Initial Admin Identity">'CN=admin'</property>
<property name="Legacy Authorized Users File"></property>

<property name="Node Identity 1"></property>
</authorizer>
```
A printout of the .p12 contents via `keytool`:
```

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: admin
Creation date: Jan 30, 2024
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=admin
Issuer: CN=nifi-ca
```

Pivoting slightly, when I attempt to use the same YAML, but use the following image:
apache/nifi:2.0.0-M1

I get a completely different error. I get an Invalid SNI error.

If there is anything you could do to point me in the right direction, I would greatly appreciate it.

[#2 · Accepted solution]

Nevermind!!!  Problem solved -- setting up the mTLS stuff on NiFi was extremely hard for me. The hardest thing, I think, is just making sure that all of the certs are properly set up and configured. I finally got that done.  Key takeaways for me (hopefully making it more simple than the documentation):
1. Because NiFi 2.0.x is now using Java 21 and Jetty 10, it's super persnickety about security, etc. The key issue here is that if you are having 'Invalid SNI' issues (Server Name Indication), it is more likely than not because you don't have your SAN (Subject Alternate Name) set up correctly in your certificates. Bottom-line here, is that Version 2.0.X doesn't allow for ip addresses anymore if you are going to secure the instance. They have to be hostnames.
2. Since you are required to get the hostname issue correct, it could get very complicated. In my case, I was already running a DNS server, so it made it a lot easier, but if you don't have a DNS server, you either need to mod your /etc/hosts file (if you are running NiFi from a local machine), or introduce a DNS server into the mix, or something similar...
3. If you want to have a secured version of NiFi running, and if you want to use it in SINGLE USER mode, that appears to still work ONLY if you access it from the local machine running NiFi, wherein you can use `https://localhost:portnumber/nifi`.
4. However, if you want to use NiFi in mTLS mode (or LDAP, etc.), then you appear to lose the capability of accessing NiFi via `localhost`. So you have to do something to resolve the DNS/Hostname issues. AND critically, your SAN information in your certificates needs to match the hostname, or it won't work properly.
5. Do not make the mistake of thinking you can generate certs without SAN information. This just doesn't seem to work, at all in version 2.0.x

I'm hopeful that this is helpful to someone else. Thanks.