Philipp Freyer created NIFI-15613:
-------------------------------------
Summary: 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
Reporter: Philipp Freyer
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)
