[
https://issues.apache.org/jira/browse/NIFI-14858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013746#comment-18013746
]
David Handermann commented on NIFI-14858:
-----------------------------------------
Thanks for the reply, feel free to follow up when available, no rush.
The situation you are describing sounds very much like the set of problems that
cert-manager was created to solve, in terms of dynamic certificate provisioning
for Kubernetes pods, based on pod hostname. It does require the load balancer
to trust the certificate issuer, but that is standard practice for TLS
configuration. Granted, it is necessary for the load balancer to be updated
with knowledge of current pod names, but that is required for request routing
to live pods.
At a basic level, the certificate distribution strategy needs to be as dynamic
as the pods themselves. This is readily achievable with solutions such as
cert-manager, but it is difficult without a service that provides a similar
level of flexibility. This is a common deployment pattern for NiFi 2, so
supporting less flexible alternatives that raise security concerns remains
problematic.
> 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: 1h 20m
> 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)
