|
22 | 22 |
|
23 | 23 | == `HTTP ERROR 400 Invalid SNI`
|
24 | 24 |
|
25 |
| -You are very likely accessing a NiFi >= 2.0 stacklet using HTTPS to secure its WebUI and an Ingress in front of it. |
26 |
| -The URL requested by the ingress-controller (such as nginx) needs to be the FQDN of the nifi service, not only the service name. |
27 |
| -You can instruct nginx ingress to use the FQDN by setting the following annotation: |
| 25 | +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. |
| 26 | +The hostname in the request must match one of the hostnames in NiFi's TLS certificate. |
| 27 | + |
| 28 | +NOTE: For complete technical background, see the https://issues.apache.org/jira/browse/NIFI-14858[upstream issue NIFI-14858]. |
| 29 | + |
| 30 | +=== When using Ingress |
| 31 | + |
| 32 | +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. |
| 33 | + |
| 34 | +For nginx ingress, configure the `upstream-vhost` annotation to use the service FQDN: |
28 | 35 |
|
29 | 36 | [source,yaml]
|
30 | 37 | ----
|
|
53 | 60 | # ...
|
54 | 61 | ----
|
55 | 62 |
|
56 |
| -For details please read on https://medium.com/@chnzhoujun/how-to-resolve-sni-issue-when-upgrading-to-nifi-2-0-907e07d465c5[this article]. |
| 63 | +For additional details, see https://medium.com/@chnzhoujun/how-to-resolve-sni-issue-when-upgrading-to-nifi-2-0-907e07d465c5[this article]. |
| 64 | + |
| 65 | +=== When using Load Balancers or other proxies |
| 66 | + |
| 67 | +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. |
| 68 | +This commonly occurs because: |
| 69 | + |
| 70 | +* The proxy uses a different hostname than what's in NiFi's certificate |
| 71 | +* NiFi is unaware of the external hostnames used to reach the proxy |
| 72 | +* Certificate management in Kubernetes makes it complex to include all possible hostnames |
| 73 | + |
| 74 | +==== Workaround: Disable SNI validation |
| 75 | + |
| 76 | +Since this scenario is common and difficult to resolve through certificate management, you can disable SNI validation in NiFi: |
| 77 | + |
| 78 | +[source,yaml] |
| 79 | +---- |
| 80 | +nodes: |
| 81 | + configOverrides: |
| 82 | + nifi.properties: |
| 83 | + nifi.web.https.sni.required: "false" |
| 84 | + nifi.web.https.sni.host.check: "false" |
| 85 | +---- |
| 86 | + |
| 87 | +WARNING: Disabling SNI validation reduces security by allowing connections with mismatched hostnames. |
| 88 | +Only use this workaround when proper certificate configuration is not feasible. |
57 | 89 |
|
58 | 90 | == `authorization_request_not_found` when using multiple NiFi nodes
|
59 | 91 |
|
|
0 commit comments