[
https://issues.apache.org/jira/browse/NIFI-14858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013743#comment-18013743
]
Lars Francke commented on NIFI-14858:
-------------------------------------
It's the end of the day here for me / responses will be slower. But I
appreciate your help on this.
Therefore just a quick answer:
It's a bit of a chicken-egg problem: In Kubernetes when the pods are started
they don't necessarily know the (often auto generated) names of the LB so there
is no way to include any names in a certificate. Then someone adds a LB at some
later point and the cert would need to be amended (which might require a
restart of NiFi - I haven't checked if it can hot-reload tbh.) and this could
happen over and over.
Other way around as well: When the LBs are started the NiFi pods (and their
names and IPs) might not be known upfront.
We're working with customers where the proper generation of these certificates
is just not possible with their cloud setups. For our on-prem customers it's
relatively easy/simple often.
> Make SNI checking configurable
> ------------------------------
>
> Key: NIFI-14858
> URL: https://issues.apache.org/jira/browse/NIFI-14858
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 2.5.0
> Reporter: Lars Francke
> Assignee: Lars Francke
> Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of NiFi 2.0 SNI certificates are required and the host must match.
> This is a problem for us (and others) when there is for example a load
> balancer in front which does not match the host name of NiFi.
> Instead of disabling the SNI check by default this makes it configurable.
>
> I propose introducing two new configuration properties:
> * nifi.web.https.sni.required (whether a SNI certificate is required)
> * nifi.web.https.sni.host.check (whether to check the Host from the SNI
> certificate against the incoming request)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
