[
https://issues.apache.org/jira/browse/NIFI-15613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Freyer updated NIFI-15613:
----------------------------------
Affects Version/s: 2.7.2
> Site2Site + Web UI not working with split certificates anymore
> --------------------------------------------------------------
>
> Key: NIFI-15613
> URL: https://issues.apache.org/jira/browse/NIFI-15613
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 2.7.2
> Reporter: Philipp Freyer
> Priority: Critical
>
> h2. Situation
> We are using multiple Apache Nifi instances (based on the docker images)
> communicating via Site2Site using TLS certificates. This worked well until
> recently (see another bug report earlier this month). We still have to
> upgrade to Nifi 2.8.0.
> However, certificate auth is broken for Site2Site (and the Web UI) currently:
> LetsEncrypt removed client auth from their certificates (with a temporary
> workaround available). This meant that we had to switch to previously used
> self-signed certificates for Site2Site authentication. These certificates are
> also used for client authentication and are trusted using our own CA
> certificate. Client authentication using those certificates worked well in
> the past.
> h2. Issue
> The issue we are seeing now is twofold:
> On one instance pair (RSA2048 server cert (LetsEncrypt, only EKU for server
> auth) and RSA4096 client cert (Self-signed, only EKU for client auth)), we
> have the issue that the server is trying to authenticate itself to all
> clients using the client certificate instead of the server certificate.
> Site2Site connections from this server to remote Nifi instances work, though,
> since they also use the same client certificate.
> In another instance pair (EC256 server cert (LetsEncrypt, only EKU for server
> auth) and RSA4096 client cert (Self-signed, only EKU for client auth)), we
> have the opposite issue: The server is serving the correct EC certificate to
> the client,s but Site2Site is broken with the error:
>
> {code:java}
> 2026-02-17 08:11:59,863 WARN [Timer-Driven Process Thread-3]
> o.apache.nifi.controller.FlowController Unable to communicate with remote
> instance RemoteProcessGroup[https://site2site-server.devel.pm:8443/nifi/]
> org.apache.nifi.controller.exception.CommunicationsException:
> org.apache.nifi.controller.exception.CommunicationsException: Unable to
> communicate with Remote NiFi at URI
> https://site2site-server.devel.pm:8443/nifi/ due to: (certificate_unknown)
> Received fatal alert: certificate_unknown
> at
> org.apache.nifi.remote.StandardRemoteProcessGroup.refreshFlowContents(StandardRemoteProcessGroup.java:948)
> at
> org.apache.nifi.controller.FlowController.updateRemoteProcessGroups(FlowController.java:3347)
> at
> org.apache.nifi.controller.FlowController.lambda$initializeFlow$3(FlowController.java:1069)
> at org.apache.nifi.engine.FlowEngine.lambda$wrap$1(FlowEngine.java:105)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
> at
> java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by: org.apache.nifi.controller.exception.CommunicationsException:
> Unable to communicate with Remote NiFi at URI
> https://site2site-server.devel.pm:8443/nifi/ due to: (certificate_unknown)
> Received fatal alert: certificate_unknown
> at
> org.apache.nifi.remote.StandardRemoteProcessGroup.refreshFlowContents(StandardRemoteProcessGroup.java:900)
> ... 9 common frames omitted{code}
>
>
> h2. Our Interpretation
> In general, it seems like the same certificate is always used for both server
> auth and client auth. This was different in the past. I remember having two
> self-signed certificates in the keystore in the past and Nifi (1.X) picking
> them up correctly. We switched to using the LetsEncrypt certificates only
> because Let's Encrypt is always adding TLS client auth EKU to their
> certificates, breaking our previous setup using self-signed certificates.
> I cannot easily use self-signed certificates only, since serving
> LetsEncryptfrom a proxy would break TLS certificate authentication with Nifi.
> I cannot just use my own self-signed certificates with TLS server and client
> auth since this would require all users to trust my self-signed CA. In order
> to mitigate this, I would have to switch to an externally trusted CA, which
> is an option I would like to avoid.
>
> h2. Suggestions
> As far as I understand, Apache Nifi hands serving the UI over to Jetty (which
> in turn hands certificate handling over to JSSE?). Jetty seems to have a way
> to give it a hint for the right key by setting a default key alias to use. Is
> there a way to do this in nifi.properties as well?
> Alternatively, is it possible to use a separate keystore for Site2Site
> communication? This way, I could avoid having two certificates in one
> keystore completely, going back to the rock-solid, reliable connections we
> were used to :-)
>
> h2. Temporary workaround
> Until May 13th, 2026, we will be able to use a temporary workaround by using
> an alternate LetsEncrypt profile tlsclient. However, this will not be
> supported beyond this date, creating the need for us to either switch the CA
> or find another way to make this work reliably. We would love to keep using
> LetsEncrypt since their integration worked great in the past.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
