docs: Document workaround to disable SNI checks #834
Conversation
There was a problem hiding this comment.
LGTM, but we should hold of merging until stackabletech/docker-images#1225 is merged.
Can you please also add a docs: prefix to the PR title? :)
If you have the time I would also be happy about a changelog entry that you can now disable the check via configOverrides (yeah, this is a docker-image thing, but users are not going to read docker-images changelog)
lfrancke
changed the title
|
I thought about that and wasn't sure. |
sbernauer
moved this from Development: Waiting for Review
to Development: In Review
in Stackable Engineering
Co-authored-by: Xenia <[email protected]>
Co-authored-by: Xenia <[email protected]>
| 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){external-link-icon}^] validation for HTTPS connections. | ||
| The hostname in the request must match one of the hostnames in NiFi's TLS certificate. |
There was a problem hiding this comment.
FWIW, this could go away with stackabletech/secret-operator#630, but might also require setting the external name in the NiFi properties.
No action needed, just mentioning it to keep it in people's minds.
|
|
||
| === 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. |
There was a problem hiding this comment.
The controller doesn't necessarily handle traffic (eg: AWS Load Balancer Controller), and applies to more the Ingress (eg: Service, Gateway).
| 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. | |
| If you're accessing NiFi through a Load Balancer or Reverse Proxy, it must forward requests using the FQDN of the NiFi service, not just the service name. |
|
|
||
| === 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. |
There was a problem hiding this comment.
| 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. | |
| When Load Balancers, API Gateways, or other proxy elements sit in front of NiFi, they might forward requests with hostnames that don't match NiFi's TLS certificates. |
or
| 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. | |
| When Load Balancers, API Gateways, or other proxy services sit in front of NiFi, they might forward requests with hostnames that don't match NiFi's TLS certificates. |
|
|
||
| * 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 |
There was a problem hiding this comment.
I disagree here.
It makes it difficult (to impossible) to add the dynamically assigned DNS name (for example, what AWS assigns to the Load Balancer, but that name isn't meant to be used directly - it is there for DNS records with the well-known name(s) to point to).
What is true here is that secret-operator doesn't allow other names to be added to the certificate (see stackabletech/secret-operator#630).
|
|
||
| ==== Workaround: Disable SNI validation | ||
|
|
||
| Since this scenario is common and difficult to resolve through certificate management, you can disable SNI validation in NiFi: |
There was a problem hiding this comment.
This is through our own fault (well, secret-operator not supporting external names), so I think we need to revise this:
| Since this scenario is common and difficult to resolve through certificate management, you can disable SNI validation in NiFi: | |
| Since this scenario cannot currently be resolved through certificate management, you can disable SNI validation in NiFi: |
|
|
||
| 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. |
There was a problem hiding this comment.
| * `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.required`: When `true`, NiFi requires that HTTPS requests include the SNI extension (containing the `server_name`). Setting to `false` allows connections without SNI certificates. |
| 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. |
There was a problem hiding this comment.
We might need to check this: Does the SNI Check check that the server_name is the same as the HTTP Host name? Or just that it is in the certificate, or both?
There is no SNI Certificate, so I'll rewrite that part, but we still need to ensure it is valid for Jetty 10.
| * `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. | |
| * `nifi.web.https.sni.host.check`: When `true`, NiFi validates that the SNI `server_name` is a valid Subject in the Certificate and that it matches the `host` header of the HTTP request. Setting to `false` disables this hostname matching check. |
If we aren't sure about the host header matching, then:
| * `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. | |
| * `nifi.web.https.sni.host.check`: When `true`, NiFi validates that the SNI `server_name` is a valid Subject in the Certificate. Setting to `false` disables this hostname matching check. |
I'm also trying to work out how we can mention Proxy Protocol v2 (PP2) in there... because load balancers can take the original server_name, and write it into the Authority header of the PP2. Jetty 10 supports PP2, so in theory it would check both PP2 Authority header (prepended to the TCP stream) or fall back to SNI server_name (in TLS Client Hello).
It's hard to validate that until we can have secret-operator add external Subject names. So maybe we can leave that for later.
|
Not sure who is supposed to resolve or reply to my comments. |
Description
Important
This should only be merged once stackabletech/docker-images#1225 is merged
Document workaround to disable SNI checks.
I took the opportunity to rewrite the entire FAQ entry.
Note
This also contains an unrelated change to fix https://rustsec.org/advisories/RUSTSEC-2025-0047 otherwise the build wouldn't work