Skip to content

docs: Document workaround to disable SNI checks #834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 2 additions & 2 deletions Cargo.nix

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

44 changes: 40 additions & 4 deletions docs/modules/nifi/pages/troubleshooting/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,16 @@ spec:

== `HTTP ERROR 400 Invalid SNI`

You are very likely accessing a NiFi >= 2.0 stacklet using HTTPS to secure its WebUI and an Ingress in front of it.
The URL requested by the ingress-controller (such as nginx) needs to be the FQDN of the nifi service, not only the service name.
You can instruct nginx ingress to use the FQDN by setting the following annotation:
This error occurs when accessing NiFi 2.0 or later, which enforces https://en.wikipedia.org/wiki/Server_Name_Indication[SNI (Server Name Indication)] validation for HTTPS connections.
The hostname in the request must match one of the hostnames in NiFi's TLS certificate.

NOTE: For complete technical background, see the https://issues.apache.org/jira/browse/NIFI-14858[upstream issue NIFI-14858].

=== When using Ingress

If you're accessing NiFi through an Ingress controller, the ingress must forward requests using the FQDN of the NiFi service, not just the service name.

For nginx ingress, configure the `upstream-vhost` annotation to use the service FQDN:

[source,yaml]
----
Expand Down Expand Up @@ -53,7 +60,36 @@ spec:
# ...
----

For details please read on https://medium.com/@chnzhoujun/how-to-resolve-sni-issue-when-upgrading-to-nifi-2-0-907e07d465c5[this article].
For additional details, see https://medium.com/@chnzhoujun/how-to-resolve-sni-issue-when-upgrading-to-nifi-2-0-907e07d465c5[this article].

=== When using Load Balancers or other proxies

When Load Balancers, API Gateways, or other proxy tools sit in front of NiFi, they may forward requests with hostnames that don't match NiFi's TLS certificates.
This commonly occurs because:

* The proxy uses a different hostname than what's in NiFi's certificate
* NiFi is unaware of the external hostnames used to reach the proxy
* Certificate management in Kubernetes makes it complex to include all possible hostnames

==== Workaround: Disable SNI validation

Since this scenario is common and difficult to resolve through certificate management, you can disable SNI validation in NiFi:

[source,yaml]
----
nodes:
configOverrides:
nifi.properties:
nifi.web.https.sni.required: "false"
nifi.web.https.sni.host.check: "false"
----

These properties control NiFi's SNI validation behavior:

* `nifi.web.https.sni.required`: When `true`, NiFi requires that HTTPS requests include an SNI certificate. Setting to `false` allows connections without SNI certificates.
* `nifi.web.https.sni.host.check`: When `true`, NiFi validates that the SNI certificate's hostname matches the incoming request's hostname. Setting to `false` disables this hostname matching check.

WARNING: Disabling SNI validation reduces security by allowing connections with mismatched hostnames. Only use this workaround when proper certificate configuration is not feasible.

== `authorization_request_not_found` when using multiple NiFi nodes

Expand Down